Hacker News Digest

I checked out the Wired article. Not recommended seems to mostly be about the fact that it's a tiny display, which some people (like the reporter) will have trouble to read. That the screen degraded didn't help of course. The reporter doesn't want to use a web dashboard to check

• Самая быстрая и надежная open-source платформа для трейдинга. Торгуйте любым классом активов в одном месте. Событийные бэктесты на любых исторических данных. Лайв-трейдинг без изменений кода.

• Решения:

  • Open Source — репозиторий на GitHub.
  • Cloud Platform — облачная платформа Nautilus Cloud.

• Компания: О нас, Команда, Партнеры, Правовое.

• Ресурсы: Документация, Образование (скоро), Блог, Начать, Discord.

• Платформа для алгоритмической торговли:

  • Интеграция данных: загрузка кастомных/сырых данных в формат parquet.
  • Построение стратегий: Python API, стрим до 5 млн строк/с, больше RAM.
  • Аналитика: моделирование рынка с наносекундной точностью, событийные результаты.
  • Быстрая итерация: экстремально быстрые бэктесты.
  • Лайв-торговля: надежный запуск, паритет кода бэктест/лайв.
  • Исполнение: высокопроизводительное low-latency исполнение на Rust.

• Классы активов:

  • Крипто: спот, фьючерсы, деривативы, опционы; нормализованные инструменты.
  • Фьючерсы: активация/экспирация, базовые активы, биржи, лоты, множители.
  • Акции: шорт-ограничения, кэш/маржин, круглые/нестандартные лоты, мульти-биржа.
  • Опционы: Греки и сигналы на внутренней шине; точные спецификации контрактов.
  • FX: спот и деривативы, базовая/котировая/расчетная валюты; биржи и ECN.
  • Беттинг: спортивные и альтернативные рынки, полный стакан, адаптер Betfair.

• Безлимитные бэктесты стратегий, площадок и рынков. Стратегии для любых инструментов и веню.

• Ключевые возможности:

  • Простые модульные компоненты: Clock, Cache, MessageBus, Portfolio, Actors.
  • Точное время: наносекундные часы для бэктеста и лайва.
  • Быстрая конфигурация: торговля на множестве веню и параметров без изменения кода стратегии.
  • Продвинутые ордера: post-only, reduce-only, OCO, OTO и др.
  • Интеграции API: быстрый коннект новых бирж и провайдеров данных.
  • Высокая производительность: ядро на Rust.

• Партнеры: Databento, OKX.

• Выразите идеи стратегий через чистый, мощный API:

  • Python API: совместим с ML/AI-фреймворками и любым Python-кодом.
  • Любые типы стратегий: настраиваемые компоненты для любой идеи.
  • Конфигурации стратегий: упрощение настройки.

• Обсуждение крутится вокруг алгоритмической торговли и платформ, с акцентом на рисках и иллюзии «успешных» стратегий: многие отмечают, что без информационного или инфраструктурного преимущества (HFT) торговля похожа на подбрасывание монетки.
• Несколько комментаторов поделились опытом: высокие проценты «успешных» сделок с редкими, но разрушительными просадками; out-of-sample провалы ML/бэктестов; необходимость чёткой «edge» (ребейты, латентность, маркет-мейкинг, арбитраж).
• Выделяют, что разработка OMS/интеграций и бэктестера — «лёгкая часть»; основная сложность — поиск и валидация стратегий и управление рисками (упоминание негативной асимметрии, LTCM, Карвер).
• Практический совет многим — предпочесть долгосрочное инвестирование (индексные фонды, buy-and-hold) вместо активного трейдинга; ряд участников подтвердили, что это повысило их результаты и снизило стресс.
• Обсуждается платформа Nautilus: впечатляющая полнота (особенно risk engine), но интеграция с брокерами (IBKR и др.) и регуляторные проверки сложны; указывается на список интеграций и сравнение с LEAN/QuantConnect.
• Скепсис к розничной алготорговле: необходимость капитала/инфраструктуры, риск банов у брокеров, низкомаржинальные «нейтральные» портфели в HFT требуют больших ресурсов; многие считают, что в одиночку стабильно зарабатывать почти нереально.
• Встречаются идеи обучающих симуляторов и простых целей (например, $1/день как POC), но общий тон — трезвый: дисциплина риск-менеджмента важнее «волшебных» моделей, а охота за стратегиями — глубокая и дорогостоящая нора.

• Недавние записи
  Архив блога

• Одно из ключевых достижений вычислений — сжатие данных: мы уменьшаем размер, сохраняя всю информацию (без потерь), передаём и восстанавливаем исходник.

• Раньше сжатие было необходимо: носители малы, сети медленны. Сейчас это не всегда критично, но по‑прежнему полезно: эта страница почти наверняка пришла к вам в сжатом виде, что ускоряет загрузку и снижает нагрузку на сервер.

• Забавно, что в 2025 мы нередко делаем противоположное. Пример: Бобу нужен новый рабочий компьютер. Его просят написать 4 абзаца обоснования. Он просит LLM сгенерировать текст и отправляет менеджеру.

• Менеджер получает длинное письмо, копирует его в LLM и просит резюме в одном предложении: «Нужен новый компьютер, старый медленный и мешает продуктивности». Заявку одобряют.

• Я называю это «инфляцией LLM»: легко превращать короткое и простое в длинное и видимо глубокое — и обратно, длинное и «глубокое» в короткое и простое.

• Это не упрёк LLM. Но стоит задуматься, почему мы раздуваем контент: в лучшем случае поощряем туманность и трату времени; в худшем — скрываем отсутствие ясной мысли. LLM лишь обнажают масштаб. Возможно, это подтолкнёт нас к изменениям!

• 2025‑08‑06 10:50 — Более раннее

• Обновления: Mastodon, Twitter, RSS, e‑mail

• Сноски:
  И, разумеется, теория информации, но здесь важны практические эффекты.

• Комментарии

• Обсуждение вращается вокруг “инфляции текста” из‑за LLM: люди генерируют лишнюю прозу для бюрократических требований, а получатели затем используют LLM для сжатия обратно до сути.
• Многие считают проблему культурной и организационной: длинные форматы служили фильтром/сигналом усилий и «критического мышления», но с LLM этот сигнал обесценился.
• Часть участников утверждает, что инфляция текста существовала и раньше; LLM лишь ускорили процесс и обнажили масштаб пустых формальностей.
• Другие видят в этом шанс: нормализовать краткость, требовать брифы/буллеты, а при необходимости поручать LLM расширение текста на стороне читателя.
• Встречаются скепсис и критика вымышленных кейсов (например, про “4 абзаца” для покупки ПК) как нереалистичных или оправдывающих бюрократию.
• Предлагаются альтернативные метрики и взгляды: оценивать модели по способности к компрессии информации; замечается, что «формальная вежливость» и сигналы статуса в языке подпитывают многословие.
• Общий вывод: инструменты генерации/суммаризации меняют баланс доверия и сигналов в коммуникации; организациям стоит переосмыслить процессы и поощрять ясность и краткость.

• Обсуждение: «About the BLOBs in Ventoy · Issue #3224 · ventoy/Ventoy».
• Страница GitHub Issues перегружена навигацией и служебными блоками (меню, поиск, вход/регистрация, продукты/решения GitHub, сохранённые запросы, уведомления о сессии и т.п.).
• Содержательная часть самого обсуждения по теме BLOBов в Ventoy в предоставленном фрагменте отсутствует: видны только заголовки разделов GitHub, элементы интерфейса и ссылки.
• Вывод: по данному отрывку невозможно извлечь детали о BLOBах в Ventoy (описание проблемы, позиции участников, решения или выводы). Чтобы перевести и сократить по сути, нужен текст самих сообщений Issue.

• Обсуждение вокруг доверия к Ventoy: часть участников не доверяет проекту из‑за рисков компрометации цепочки поставок и неоднозначной позиции мейнтейнера по “блобам”; другие продолжают пользоваться из‑за удобства.
• Некоторые сообщают о многолетних нерешённых вопросах безопасности и подозрениях к iVentoy (упоминание обходов сертификации на Windows), запрашивают ссылки и уточнения.
• Практический опыт разделился: у одних Ventoy “просто работает”, в т.ч. с Arch и Windows; у других встречались проблемы с Arch или путаница в установщиках из‑за EFI/ISO, приходилось возвращаться к “одиночным” флешкам.
• Звучит альтернатива Ventoy: сетевой бут (PXE) с набором инсталляторов и утилит, а также USB‑корпуса, эмулирующие DVD, как способ уйти от несовместимостей.
• Пользователи ценят ключевые фичи Ventoy: мульти‑ISO на одной флешке и возможность хранить обычные файлы параллельно.
• Новички в теме просят источники по “драме” и объяснения; часть скептиков не готова доверять Ventoy до появления прозрачной сборки без закрытых бинарников.
• В стороне идёт языковая ветка: уточнение, что “blob” исторически не акроним, хотя в базах данных закрепилось “Binary Large Object”; обмен шутками и ссылками.

Я работал удалённо ещё до моды. В первой большой компании нас было двое в Варшаве, остальные — в Осло. Менеджер сказал: «Команда тебя приняла». Парадокс? Нет: был IRC-канал, где мы не только кодили, но и болтали о «Стартреке» и котиках. Компания создала онлайн-«кухню», и люди здоровались, спрашивали «как дела?» — как в офисе.

Пандемия. Я в консалтинге, всё как всегда: рабочие и оффтоп-каналы в Matrix. Нам поручили клиента, который «внезапно» стал удалённым. Менеджер велел включать камеры «ради командного духа». Мы купили вебки и ржали в чате. У клиента не было оффтопа; люди знали друг друга только по рабочим ролям. Ревью превращались в разборки, потому что никто не играл вместе вечерами и не пил пиво по пятницам.

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

Недавно пришёл в «remote-first» компанию без офиса. На собеседовании хвалил оффтоп, и мне ответили: «У нас куча каналов и рандомных кофе-ботов». А по факту — тишина. В #music сбросили ссылку на клип и разошлись. Коллега пояснил: «Релиз на носу, все боятся выглядеть бездельниками». Так уже несколько месяцев.

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

• Участники обсуждают, как «человеческий элемент» в работе (оффтоп-общение, дружба) повышает удовлетворённость, но может выродиться в клановость и изоляцию.
• Переход на удалёнку усилил страх слежки: в офисе кофе-пауза была приватной, в Slack всё может читаться HR/IT.
• Корпоративная культура часто подавляет неформальность: стартапам позволено шутить, крупным компаниям важно минимизировать конфликт.
• Некоторые считают, что коллеги не обязаны быть друзьями (особенно в Германии), другие подчёркивают пользу доверия и симпатии.
• Технические решения (DM, каналы без истории) могут частично заменить «водопроводные разговоры», но не решают проблему культуры.

Everybody is talking about Chrome, but I tell ya what I have that disabled on my Android in favor of Firefox. Firefox on mobile with full-fat uBlock Origin is the closest thing to parity with desktop web access you can get.I don't just block ads, I block elements on sites I don't

Краткий отчёт о замене PTAC на мини-сплит в бруклинской квартире

• Цена: ~40 000 $ (включая заделку старых оконных проёмов).
• Причина: четыре новых PTAC-а 2023 г. (Islandaire) шумели, зимой переключались на дорогой электро-обогрев, текли и испортили полы. Самый высокий счёт за электричество — 1 200 $.

Выбор системы
Геотермальные и крышные варианты не прошли — только мини-сплит с одним наружным блоком во дворе и четырьмя внутренними.

• Ребейт 7 000 $ не дали: старые PTAC уже были тепловым насосом.
• Подрядчики: Mitsubishi-партнёр — 53 000 $; Ice Age — 31 000 $ (без заделки дыр). Взяли Ice Age + отдельный «заделочный» подрядчик.

Монтаж
Планировали 1–2 недели, вышло > месяца. Начали с опозданий, работали урывками:
1 день — прорезали отверстия;
2 день — проложили трубы;
3 день — расширили отверстия, потому что первые были малы.
Бригадир и владелец фирмы появлялись пару раз за весь проект.

Результат

• Стало тише и температура стабильнее.
• Деньги на электричестве не отобьём, но жить комфортнее.
• Совет знакомым: «Ice Age? …Наверное, поищите кого-то другого».

• У автора установка мини-сплита в бруклинской квартире обошлась в $42 000 и заняла > месяца, а зимой счёт за электричество доходил до $1000/мес.
• Комментаторы сходятся: квартирa невероятно продувается, и прежде чем ставить тепловой насос, нужно было провести энергоаудит и герметизировать оболочку.
• Качество подрядчиков в США вызывает жалобы: цены в 3-4× выше стоимости оборудования, сроки растягиваются, результат нередко посредственный.
• Многие советуют DIY: опытные пользователи ставили мульти-сплит-системы за выходные за <$2 000, включая вакуумирование и заправку.
• В Бразилии и других странах такие же работы стоят в десятки раз дешевле и выполняются за день.

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

В слайдах он показал множества: «программы, где Python достаточно быстр» — подмножество «всех Python-программ», а снаружи — «все возможные программы». В идеале Python должен подходить для всех; пока что задачи, требующие максимума от процессора, не могут быть на Python. Он хочет расширять «внутренние круги».

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
    return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world'))  # type: ignore

Чекер доволен, но семантика сложения уже другая. Аннотации бесполезны для оптимизации и скорости, если их не гарантирует рантайм. Более того, в Python легально перегружать операции, меняя поведение в рантайме, что разрушает предпосылки для агрессивных оптимизаций.

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.

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

Tailscale — это по сути оркестрация WireGuard с приятными надстройками. Продукт по подписке, но у него очень щедрый бесплатный тариф для личного использования. Клиенты — с открытым исходным кодом; есть и сторонний контроль-сервер Headscale, если не хочется облака.

Базовое подключение

Tailscale позволяет легко связать устройства, даже если они не торчат в интернет. Ставите клиент на телефон/компьютер/сервер/Raspberry Pi, авторизуете — и он общается с остальными по приватным IP Tailscale.

Это обычная идея VPN, но здесь всё просто: не нужно настраивать сеть и раздавать ключи — ставите клиент и логинитесь.

Например, мой домашний автоматизационный сервис на Raspberry Pi за двумя роутерами: поставил Tailscale, вошел — и сразу могу SSH с ПК или телефона, даже из разных сетей.

Есть особая поддержка SSH: Tailscale принимает подключения на 22 порт с tailnet и сам выполняет аутентификацию. Никаких ключей и паролей: вошли в Tailscale — можете войти на машину. Особенно удобно с телефона, где управлять ключами неудобно.

Можно публиковать не целую машину, а отдельные сервисы как отдельные узлы tailnet: есть официальный Docker-образ, Go-библиотека, и сторонние инструменты (например, мои Centauri и tsp).

Это больше, чем VPN

Чтобы не запоминать IP, я долго вручную добавлял DNS-записи. Перешел на MagicDNS — он автоматически создает DNS по имени машины.

Сначала меня смущало, что он меняет резолвер на устройствах — “слишком магично”. Разобрался, привык. Можно задать и свой upstream DNS. Я везде использую NextDNS, и Tailscale сам настраивает его на всех устройствах.

Помимо коротких имен, есть формат machine.your-tailnet.ts.net. Его можно «перебросить» на глобальную маршрутизацию и получить TLS-серты.

Нужно быстро показать локальный сервис? Включите funnel: tailscale funnel 127.0.0.1:8080 Без доп. опций сервис будет доступен по HTTPS:443. Дайте ссылку https://machine.your-tailnet.ts.net — трафик пойдет на ваш 8080. У посетителей Tailscale не нужен. Пользуюсь редко, но удобно.

Команда serve делает похожее, но только внутри tailnet. Так же работает Docker-образ Tailscale для публикации обычного сервиса. Для тестов с телефона: вместо танцев с Wi‑Fi/локалхостом/IP просто запускаю tailscale serve и захожу с устройства.

• Включение tailscale funnel мгновенно привлекает ботов, сканирующих новые HTTPS-сертификаты из CT-логов.
• Пользователи делятся альтернативами: Headscale, NetBird, Nebula, Zerotier и «чистый» WireGuard.
• Mullvad-интеграция позволяет использовать выходные ноды Tailscale для смены геолокации.
• Настоятельно не рекомендуют запускать dev-серверы и OIDC-серверы через funnel из-за риска блокировки и атак.
• Чтобы не светить домены, применяют wildcard-сертификаты и нестандартные порты.
• Tailscale собирает телеметрию по умолчанию; её можно отключить, но это не анонимный VPN.

• Сгенерированное ИИ изображение, где ИИ руками «отвергает» меня. Очень мета.

В октябре 2024 Anthropic представила «Claude Computer Use», позволяющую ИИ управлять компьютером, копировать данные из браузера в таблицы и т.п. Я поддерживаю библиотеку для управления компьютером и этой весной решил разобраться, как они это делают. К моему удивлению, Anthropic использует мою библиотеку enigo.

Проверить использование enigo в Claude Desktop для macOS можно так:

• 7z x Claude.dmg
• perl -nle 'print $& while /.{0,67}enigo.{0,30}/g' Claude/Claude.app/Contents/Resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод содержит путь к enigo-0.2.1/src/macos/macos_impl.rs

На Windows:

• 7z x Claude-Setup-x64.exe
• 7z x AnthropicClaude-0.11.6-full.nupkg
• perl -nle 'print $& while /.{0,75}enigo.{0,26}/g' Claude-Setup-x64/AnthropicClaude-0.11.6-full/lib/net45/resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод указывает на enigo-0.2.1/src/win/win_impl.rs

Я горжусь, что enigo дорос до продакшена у компании с огромным бюджетом. Эмуляция ввода сложна из‑за слабой документации и платформенных особенностей. На мой взгляд, enigo — отличный выбор: работает на Windows, macOS, *BSD и Linux (Wayland, X11, libei) без root; написан на Rust (безопасность памяти, высокая скорость); самый популярный на crates.io (~300k загрузок, 1200+ звёзд). И всё же тревожно, что мой хобби‑проект установлен на тысячах устройств.

Сколько я на этом заработал? Нисколько: enigo под MIT‑лицензией — можно бесплатно использовать. Взамен — звёзды на GitHub и счётчик загрузок.

Интересно, что Claude Desktop — Electron‑приложение, но есть только для macOS и Windows. Сообщество запустило его на Linux, заменив вызовы enigo заглушками, хотя enigo кроссплатформенна — любопытный выбор.

Через знакомых я узнал об открытой роли в команде, делавшей секретную, ещё не выпущенную функцию Claude Desktop с enigo. Подал заявку, ждал. В итоге пришло письмо: команда не успевает рассматривать дополнительные заявки.

Я бы с радостью поработал в Anthropic: сделать аналог Computer Use, довести Claude Desktop до Linux, вложить свой опыт в эмуляцию ввода и полноценно отполировать enigo, чтобы Anthropic концентрировалась на моделях, а не на капризах ввода.

В целом я счастлив, что enigo в Claude Desktop, и всем об этом рассказываю. Забавно думать, что я метафорически дал Claude руки и ноги — и получить отказ. Письмо написал человек или сам Claude? По крайней мере, теперь я, наверное, в безопасности…

• Обсуждение вокруг автора OSS-библиотеки enigo, которую, по словам поста, использует Claude Desktop; при попытке податься в Anthropic он получил авто‑отказ без рассмотрения, что вызвало резонанс.
• Многие считают, что заявку, вероятно, даже не читали из‑за перегруженных или автоматизированных HR/ATS‑процессов; советуют искать тёплый интро к менеджеру, а не подаваться «в общий ящик».
• Поднята тема лицензий: permissive (MIT) позволяет корпорациям брать код без вклада; участники предлагают рассмотреть MPL/EUPL, Fair Source или даже целевые ограничения, хотя применимость и исполнение спорны.
• Несколько комментаторов призывают Anthropic хотя бы поблагодарить автора, дать консультационный контракт или символическую компенсацию; другие напоминают, что компания волна отбирать кого хочет.
• Обсуждаются возможные факторы отказа: геолокация (США vs Европа), визы, несоответствие профиля «AI‑инженеру», парадоксы найма и предпочтение «низкопрофильных» кандидатов.
• Приводятся похожие кейсы из индустрии: от игнора мейнтейнеров до неудачных интервью у компаний, зависящих от их софта.
• Общий вывод: современный тех‑набор страдает от автоматизации и перегрузки; для кандидатов критичны нетворкинг, прямой контакт с нанимающим менеджером и стратегия видимости, а для OSS — осознанный выбор лицензии.