Hacker News Digest

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

Причины избыточного сотрудничества включают желание быть полезным, недостаточную конкретность в запросах обратной связи и отсутствие ясности в определении ответственного. Автор предлагает решения: по умолчанию отправлять код (pull requests), а не обсуждать в Slack, и сокращать количество участников в обсуждениях. В компании даже подсчитали 175 упоминаний фразы "давайте обсудим" в Slack, что свидетельствует о проблеме.

• Обсуждение в основном вращается вокруг вопроса, когда коллаборация становится вредной: отсутствие четкого владельца решения, размывание ответственности, «bikeshedding» и замедление процесса.
• Участники спорят, где именно граница между полезной обратной связью и «параноем» в стиле «дайте мне знать, что вы думаете об этом» и «почему вы не сделали это так, как я бы хотел».
• Некоторые участники подчеркивают, что не всякая коллаборация вредна — только та, что не имеет четкой структуры и владельца решения.
• Обсуждение также затрагивает тему, что важно различать «коллаборация» (которая может быть полезной) и «безконтрольная коллаборация» (которая может быть вредной).

Современные терминалы ограничены решениями, принятыми ещё в 1980-х, и состоят из четырёх компонентов: эмулятора терминала, псевдотерминала (PTY), оболочки (shell) и запускаемых программ. Автор отмечает, что внутренняя структура терминалов — это "куча", где многие решения невозможно изменить из-за исторического наследия. В качестве примера приводится цитата Джулии Эванс: "Внутренности терминалов — это беспорядок. Большая часть этого именно такая, потому что так кто-то решил в 80-х, и теперь это невозможно изменить".

В качестве альтернативы традиционному терминалу автор предлагает использовать Jupyter Notebook как модель для будущего терминала, предлагающую такие возможности, как высококачественное рендеринг изображений, функцию "перезапустить с начала" и возможность редактирования представлений кода и вывода. Статья описывает четыре этапа создания такого терминала: транзакционную семантику, постоянные сессии, структурированный RPC и интерфейс, похожий на Jupyter.

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

Knokke представляет собой новый высокоскоростной сканер 35 мм пленки, который позиционируется как "новая эра сканирования". Устройство предлагает впечатляющие характеристики: разрешение 4064 DPI, динамический диапазон 120 дБ и глубину цвета 48 бит, при этом способно отсканировать всю катушку всего за несколько минут. Сканирование происходит с помощью кастомной оптики и современного сенсора, что обеспечивает высочайшее качество при доступной цене.

Сканер работает на собственном программном обеспечении Korova — легком приложении на C++, нативном для Linux, macOS и Windows. Это позволяет отказаться от устаревших ПК и использовать современный plug-and-workflow. Каждому кадру можно задать индивидуальные настройки, которые повторяются при последующих сканированиях для консистентных результатов. Цена запуска составит €999, включая и сканер, и программное обеспечение.

• Стоимость сканера Knokke составляет €999, что вызывает сравнение с ценой на подержанные DSLR-установки и вызывает обсуждение ценообразования.
• Отсутствие примеров сканов и отсутствие ИК-сенсора для удаления пыли и царапин вызывает критику.
• Обсуждается, что цена может быть оправдана для энтузиастов, которые ценят дизайн и удобство использования.
• Некоторые участники обсуждения выражают сожаление, что сканер не поддерживает 120 формат, а также отсутствие автоподатчика.
• Участники также обсуждают, что стоимость может быть оправдана для тех, кто ищет высокое качество сканирования и готов заплатить за него.

Оптимизирующие компиляторы отслеживают эффекты каждой инструкции в промежуточном представлении (IR), которые могут варьироваться от полного отсутствия эффектов до записи в конкретную переменную или полностью неизвестных воздействий. Автор рассматривает эту тему как продолжение предыдущего поста об IR, подчеркивая важность правильных вопросов: не "какой это код?", а "какие эффекты он производит?". Эффекты помогают компилятору определять, можно ли переупорядочивать, дублировать или удалять инструкции, особенно когда речь идет о доступе к памяти, где ключевым фактором является алиасинг (ссылки на один и тот же объект).

В статье представлены два основных подхода к представлению эффектов: битовые множества и списки диапазонов кучи. Автор подробно разбирает пример компилятора Cinder (Python JIT), который использует битсет под названием AliasClass для отслеживания эффектов работы с кучей. Каждый бит в этом множестве представляет отдельное расположение в куче, а операции объединения и пересечения выполняются с помощью побитовых операций. Интересно, что этот подход аналогичен представлению решетки типов в Cinder, где каждый бит неявно представляет множество, а операции над множествами реализованы через битовые операции И и ИЛИ.

• Пользователи ожидали, что статья будет про эффект Манделы или уязвимости Spectre из-за заголовка.
• Один участник отметил, что теперь они случайно прочитали про компиляторы.
• Завершающий комментарий содержит шутку про "Men in Black" и изменение логотипа Fruit of the Loom.

Роберт Глейзер провел эксперимент, используя агентный цикл «генерация-оценка-улучшение» для создания SVG-изображения пеликана на велосипеде. Модели получали доступ к Chrome DevTools для конвертации SVG в JPG и использовали зрение для самокоррекции. Тестируемые Claude Opus, Sonnet, Haiku, GPT-5 Medium, GPT-5-Codex и Gemini 2.5 Pro делали 4-6 итераций, самостоятельно решая, когда остановиться. Эксперимент основан на бенчмарке Симона Уилльсона, который используют даже лаборатории в маркетинге новых моделей.

Claude Opus добавил цепь и спицы, улучшив механическую достоверность; Sonnet делал тонкие доработки кривых и теней; Haiku за 6 итераций настойчиво исправлял пропорции. GPT-5 Medium и Codex показывали постепенное улучшение, а Gemini 2.5 Pro демонстрировал стабильные результаты. Ключевое открытие: модели способны к самооценке и самокоррекции без детальных указаний, сохраняя дух оригинального абсурдного запроса. Использование единого рендерера обеспечило объективность сравнения.

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

К сожалению, предоставленный текст не содержит статьи "FFmpeg to Google: Fund Us or Stop Sending Bugs" от The New Stack. Вместо этого это форма подписки на их рассылку. Чтобы я мог создать точный пересказ статьи (~170 слов на русском в Markdown), пожалуйста, предоставьте текст самой новости.

Как только вы поделитесь содержанием статьи, я сразу подготовлю лаконичный пересказ, выделив главную идею и ключевые факты/цифры/цитаты, строго следуя вашим инструкциям.

• Крупные корпорации (Google, Amazon и др.) ожидают, что open-source проекты будут бесплатно исправлять уязвимости, которые они же и находят, но при этом не предлагают ни ресурсов, ни финансирования.
• Сторонники FFmpeg отвечают, что если проект не может позволить себе тратить время на бесплатную разработку, то это не значит, что он обязан это делать, и что крупные компании могут просто отказаться от использования open-source, если не хотят платить.
• Обсуждение вышло за рамки конкретной ситуации и затронуло более широкий вопрос о том, как корпорации используют open-source без всякой отдачи.
• Некоторые участники обсуждения подняли вопрос о том, что если FFmpeg и подобные проекты не могут позволить себе тратить ресурсы на бесплатную разработку, то, возможно, им стоит пересмотреть свою модель лицензирования или найти другие способы монетизации.
• В целом, обсуждение подняло волну обсуждений о том, как корпорации используют open-source без всякой отдачи, и как это влияет на устойчивость проектов.

• Windows Terminal development focuses on improving throughput and performance, with recent updates significantly boosting speed.
• Users compare terminal performance across platforms, noting macOS's Terminal.app and alternatives like Ghostty, with some pointing to benchmarks showing macOS may lag.
• Feature requests include serial communication support (e.g., Serial/RS232) and better integration with tools like Tera Term, alongside discussions on handling output buffering.
• Some users highlight Windows Terminal's advantages, like WSL integration, while others note limitations compared to Linux/macOS terminals.
• Discussions acknowledge Windows as a multi-purpose OS, not just for gaming, with many developers using it daily for development, especially with WSL.

• OpenAI модель часто искажает лица и детали, придавая изображения оранжевый оттенок, что воспринимается как недостаток.
• Оценка качества генерируемых изображений субъективна: пользователи спорят о приоритетах (реализм vs стиль, цвета), что затрудняет объективное сравнение моделей.
• Gemini склонен возвращать изображения без изменений, Seedream поддерживает высокое разрешение, но меняет цветовую палитру, NanoBanana эффективен при условии совпадения стилей.
• Текущие ИИ-инструменты для редактирования изображений имеют ограничения и не всегда точно следуют запросам, что требует от пользователей адаптации и экспериментов.
• Появление генеративного ИИ вызывает дискуссии о будущем профессий художников и иллюстраторов, но мнения разделяются: одни видят угрозу, другие — эволюцию инструментов.

Стандартный алгоритм Ланцоса для вычисления матричных функций требует значительных ресурсов памяти: хранение n×k базисной матрицы, которая растёт с каждой итерацией. Для задачи с 500 000 переменными и 1000 итерациями это около 4 ГБ только для базиса. В статье представлен двухпроходной вариант алгоритма, требующий всего O(n) памяти ценой удвоения числа матрично-векторных произведений. При грамотной реализации этот подход не только экономит память, но и может работать быстрее для определённых задач.

Автор подробно описывает реализацию на Rust, включая шаги рекуррентного вычисления, итератор для управления состоянием, первый проход (вычисление разложения) и второй проход (восстановление решения). Интересно, что теоретические ожидания производительности не всегда подтверждаются на практике, особенно для средних по размеру матриц. Весь код доступен на GitHub, а технический отчёт с доказательствами и дополнительными экспериментами можно скачать отдельно.

• Обсуждение охватывает редкий случай, когда матрица и векторы помещаются в кэш, но базис не помещается, и показывает, что алгоритм Ланцоша может быть реализован без реортогонализации, что экономит O(n²) памяти и O(n²) FLOP в обмен на O(n) дополнительных итераций.
• Участники обсуждают точность двухпроходного подхода, влияние потери ортогональности на точность и применимость метода, а также то, что влияние на точность может быть меньше, чем погрешность самого алгоритма Ланцоша.
• Также обсуждается выбор языка для реализации алгоритма, причем участники делятся опытом и мнением о том, какие языки лучше всего подходят для высокопроизводительной численной линейной алгебры.
• В конце обсуждение сдвигается к тому, что автор может в будущем опубликовать расширенную версию статьи, и что читатели могут ожидать увидеть ее в будущем.

Context for this submission:Apple releases the iPhone Pocket: https://www.apple.com/newsroom/2025/11/introducing-iphone-po...HN discussion: https://news.ycombinator.com/item?id=45885813 I always have a little chuckle when I see people holding a tiny delicate smartphone in a massi