Hacker News Digest

This pops up every few years, and I bet once it gets in it never goes away. It seems asymmetric that one side only has to win once to win permanently while the other side has to win constantly. Is there any mechanism to stop this in the EU and make this kind of legislation explic

303Gen

• Обсуждение посвящено веб-инструменту в стиле TB-303: пользователи хвалят звук, музыкальность и авто-генерацию совместимых полиритмов для баса, лида и дрона, отмечают ностальгию по ReBirth и 90-м.
• Автор сообщает, что проект старый и незавершённый; добавил полифилл для cancelAndHoldAtTime в Firefox и выделил часть таймкипинга в библиотеку beatstepper.
• Многие просят открытый исходный код, локальный запуск, экспорт MIDI/стемов, визуализацию паттернов (пиано-ролл), сохранение/загрузку, MIDI синхронизацию и транспорт, а также продолжение воспроизведения при Regenerate.
• Есть баг-репорты: не работало в Firefox до полифилла, в Chromium после Stop остаётся тихий хвост/эхо, иногда нужно жать Stop несколько раз.
• Пользователи делятся альтернативами и вдохновляющими ссылками: Endless Acid Banger, roland50.studio, музыка Vitling, ивенты Acid August.
• Инструмент вызывает желание вернуться к электронной музыке; звучание напоминает Frank Klepacki/Red Alert 2, Dynamix на C64; просят добавить 909-кит.
• Автор кратко описал генерацию: ноты из выбранной гаммы/октавы, деление паттерна на чанки с вероятностным копированием/обновлением и настройкой повторов; сообщество хочет статью о методе.

• Ультрадешёвые £16-часы удивляют функционалом, но вызывают вопросы о происхождении и приватности.
• Недостающие резисторы в USB-C порте мешают зарядке «родными» кабелями; проблема типична для дешёвых устройств.
• Amazfit, Garmin, COROS показывают, что недорогие/спортивные часы могут жить недели без подзарядки и работать офлайн.
• Пользователи мечтают об открытой прошивке и стандартных контактах вместо USB-C ради водозащиты.
• Apple Watch критикуют за суточную автономность, несмотря на цену в 28× выше.

I’ve used the reverse. When making a new module I’ve let the llm make up an api and I’ve used the names suggested as inspiration of what might come natural to others, to make the use more intuitive. > LLMs hallucinated a package named "huggingface-cli" [...] it is not the name of

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”; обмен шутками и ссылками.

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

Добро пожаловать на 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/параллельных подходов, но признают их практические ограничения.