Hacker News Digest

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

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

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

Beets — это система управления медиатекой для одержимых музыкой фанатов. Программа автоматически каталогизирует вашу коллекцию, улучшая метаданные через базу данных MusicBrainz. Благодаря архитектуре, построенной как библиотека, beets может практически всё: получать обложки альбомов, тексты песен, жанры, темп, уровни ReplayGain и акустические отпечатки. С помощью плагинов система также умеет конвертировать аудио в любые форматы, находить дубликаты и недостающие треки.

Уникальность beets — в гибкости расширений. Если нужной функции нет, написать плагин на Python удивительно просто. Метаданные можно получать из MusicBrainz, Discogs или Beatport, либо угадывать по именам файлов или акустическим отпечаткам. Для удобства предусмотрен веб-интерфейс с поддержкой HTML5 Audio. Установка выполняется одной командой: pip install beets, после чего доступно подробное руководство для начинающих.

• Обсуждение вращается вокруг инструментов для управления музыкальной коллекцией: beets, MusicBrainz, Navidrome и их альтернативы.
• Участники делятся личными workflow: покупка на Bandcamp, импорт в beets, автоматическое переименование и теггинг, а затем синхронизация с Navidome через Rclone.
• Обсуждаются сложности с автоматическим теггингом и необходимостью вручную добавлять релизы в MusicBrainz.
• Поднимается вопрос о том, как обрабатывать музыку, которая еще не в базах данных, и как быть с жанрами, которые различаются в разных источниках.
• Участники обмениваются советами по конфигурации и использованию этих инструментов и обсуждают их кривые и недостатки.

Автор создал высокопроизводительную систему продажи билетов TigerFans с использованием TigerBeetle, финансовой базы данных для транзакций. Система достигла показателя в 977 бронирований билетов в секунду, что в 15 раз быстрее, чем базовый показатель продажи билетов на концерт Oasis (65 билетов в секунду). Этот образовательный проект превратился в 19-дневный оптимизационный марафон, демонстрирующий потенциал TigerBeetle для решения задач с экстремальной нагрузкой.

В основе системы лежит модель двойной бухгалтерии, где билеты представлены как финансовые транзакции. Для каждого типа билетов создаются три счета: Operator (весь инвентарь), Budget (доступные к продаже) и Spent (проданные). Ключевая особенность — использование флага DEBITS_MUST_NOT_EXCEED_CREDITS, который архитектурно предотвращает перепродажу билетов. Реализация на Python с FastAPI, SQLite и симулированным платежным провайдером позволила создать рабочую демо-версию с двухфазным процессом оформления и автоматическим аннулированием просроченных резервирований.

Идея родилась из твита основателя TigerBeetle Joran Dirk Greef, который назвал создание такой системы "слишком простым". После демонстрации команды TigerBeetle, автор получил вызов — превзойти показатели продажи билетов Oasis. Это вдохновило на глубокую оптимизацию, доказав, что даже на Python можно достичь выдающейся производительности при правильной архитектурной основе.

• Продажа билетов на концерты часто создаёт иллюзию быстрой распродажи, но на деле билеты просто резервируются ботами и перепродажниками, а не покупаются.
• Tigerbeetle достигает высокой пропускной способности за счёт пакетной обработки транзакций, но при этом неясно, насколько это влияет на надёжность и устойчивость системы.
• Пользователи отмечают, что при использовании Tigerbeetle важно понимать, что применение его в системе продажи билетов не обязательно приведёт к улучшению UX, так как узким местом остаётся не транзакционная пропускная способность, а управление очередями и процессом покупки.

Автор рассказывает, как он создал свой собственный класс AppVersion для сравнения версий, но затем обнаружил, что в Ruby уже есть встроенный Gem::Version, который делает то же самое, но лучше. Он заменил свой класс на встроенный и призвал сообщество делиться знаниями, чтобы избежать изобретения велосипедов.

• Участники восхищаются элегантностью и лаконичностью Ruby, особенно в реализации классов вроде AppVersion, и отмечают его выразительность по сравнению с TypeScript, Elixir и другими языками.
• Подчеркивается мощь метапрограммирования Ruby и его роль в развитии любви к программированию, хотя есть критика по поводу документации и экосистемы.
• Сравниваются реализации AppVersion в других языках (Python, Java, Scala), где признается сходство в выразительности, но отмечаются различия в синтаксисе и подходах.
• Упоминается ностальгия по Rails и его современное состояние, а также скрытые возможности стандартной библиотеки Ruby.
• Есть критика Ruby за "скрытые опасности" (footguns) и проблемы с масштабированием, а также за то, что экосистема Rails затмевает сам язык.

Thomas Ptacek утверждает, что каждый должен написать агента на основе больших языковых моделей, чтобы по-настоящему понять эту технологию, независимо от своих скептических или восторженных взглядов. Как и обучение езде на велосипеде, практический опыт дает более глубокое понимание, чем абстрактные концепции. Автор подчеркивает, что создание агента оказывается удивительно простым процессом, который приносит больше практической пользы, чем можно ожидать.

Пример кода в статье демонстрирует базовую реализацию агента с использованием всего 15 строк кода через API OpenAI. Интересно, что контекстное окно в этом случае — просто список сообщений, а многопользовательский диалог поддерживается путем сохранения истории. Автор отмечает, что сам LLM является stateless-черным ящиком, а иллюзия непрерывного диалога создается разработчиком. Даже если многие специалисты не сочтут этот пример полноценным агентом (который должен использовать инструменты), добавление инструментов также оказывается простой задачей.

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

Hypothesis 6.145.1 — это библиотека для property-based тестирования в Python. Вместо написания тестов для конкретных входных данных, разработчики описывают диапазон входных значений, а Hypothesis самостоятельно генерирует случайные тесты, включая граничные случаи, которые могли быть упущены. Пример тестирования функции сортировки демонстрирует использование декоратора @given со стратегиями для списков целых чисел или чисел с плавающей точкой, где библиотека генерирует случайные списки для сравнения пользовательской реализации со встроенной функцией sorted().

Документация структурирована для разных уровней пользователей: от краткого руководства для начинающих до подробного API-справочника. В ней представлены разделы с обучающими материалами, практическими руководствами для специфических сценариев и объяснениями для углубленного понимания библиотеки. Библиотека активно развивается с 2013 года и поддерживается сообществом, что делает её надежным инструментом для повышения качества тестирования в Python-проектах.

• Property-based testing (PBT) выявляет крайние случаи, которые обычные тесты могут пропустить, но требует «оракула» или спецификации, что делает его менее универсальным инструментом.
• Основной барьер внедрения PBT — это не только отсутствие знаний, но и необходимость переосмыслить подход к тестированию и, возможно, саму архитектуру кода.
• В отличие от классических примеров, PBT требует, чтобы разработчик формализовал свой код и его свойства, что делает его менее доступным для специалистов, не знакомых с формальными методами.
• Несмотря на то, что Hypothesis и подобные инструменты делают PBT доступным на практике, они не решают фундаментальную проблему: для сложных систем требуется либо сравнение с другой реализацией, либо формальная спецификация, что делает PBT менее применимым в таких случаях.

Представлен bluetui - текстовый интерфейс (TUI) для управления Bluetooth-устройствами в Linux. Инструмент предлагает удобное консольное решение для взаимодействия с Bluetooth без необходимости использования графических интерфейсов. Разработанный на Python, проект обеспечивает интуитивное управление подключениями, сканированием устройств и настройками через текстовый интерфейс.

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

• bluetui и подобные инструменты демонстрируют, что TUI-утилиты могут быть не только удобными, но и важными для решения повседневных задач, таких как управление Bluetooth-устройствами, что вызывает у пользователей желание попробовать Rust, даже если они раньше не рассматривали его.
• Пользователи отмечают, что такие инструменты как bluetui делают процесс решения задач более плавным и простым, и что они ценят простоту использования TUI-утилит в сравнении с GUI-альтернативами.
• Некоторые комментаторы подчеркивают важность простоты и удобства использования TUI-утилит, особенно в контексте таких инструментов как bluetui, и как это может повлиять на выбор языка программирования, так как Rust используется в таких проектах.
• Некоторые пользователи выражают желание попробовать Rust, даже если они раньше не рассматривали его, из-за таких проектов как bluetui, что подчеркивает влияние таких инструментов на выбор языка программирования.
• Некоторые комментаторы также подчеркивают, что такие инструменты как bluetui делают процесс решения задач более плавным и простым, и что они ценят простоту использования TUI-утилит в сравнении с GUI-альтернативами.

За десять лет автор прошёл путь от веб-разработчика до специалиста по базам данных, присоединившись к EnterpriseDB, где работает над pglogical и Postgres Distributed. Его карьера началась в 2014 году с JavaScript и Python, затем он стал менеджером инженеров. Прорывным моментом стало 2020 год, когда проблемы с производительностью его сервиса заставили его изучить индексы и структуры данных. Он создал образовательные проекты, включая простую in-memory SQL базу данных, и построил сообщества вроде Software Internals Discord и /r/databasedevelopment.

После неудачной попытки запустить собственный стартап в 2021-2023 годах и работы в TigerBeetle автор искал позицию именно разработчика баз данных, а не DevOps-инженера для работы с базами. Несмотря на нетрадиционный путь (он бросил колледж) и сомнения работодателей, он получил три предложения на работу над расширениями Postgres на C и Rust. Выбрав EnterpriseDB, компанию с 20-летней историей и одним из крупнейших вкладчиков в развитие Postgres, он предпочёл стабильность ранним стартапам, в которых работал последние три года.

• Сообщество обсуждает, как трудно сменить специализацию, если ты уже «записан» в базе данных как специалист в области X, и как это влияет на найм и карьерные возможности.
• Участники делятся личным опытом: кто-то ушел в разработку на C/C++ и Rust, кто-то перешел в SRE или DevOps, кто-то пытается попасть в компиляторы.
• Обсуждается, что рекрутеры и системы найма не видят за пределами ключевых слов в резюме и не учитывают site-reliability, DevOps и прочие смежные навыки, что делает смену специализации еще более сложной.
• Участники делятся советами, как обойти эту систему: делать сайд-проекты, которые демонстрируют навыки в новой области, участвовать в open-source, писать блоги и статьи, и так далее.
• Также обсуждается, что важно не только выждать подходящий момент, но и быть готовым пойти на уменьшение зарплаты и не бояться начать с более низкой позиции, что может быть ключом к переходу в новую область.

Команда Skald переписала бэкенд с Python на Node.js всего через неделю после запуска, идя против стандартного совета стартапам сначала "делать то, что не масштабируется". Основная причина — сложность с асинхронностью в Python, особенно при работе с Django. Автор отмечает, что писать качественный асинхронный код на Python "очень сложно и неинтуитивно", в отличие от JavaScript с его event loop или Go с goroutines.

Django до сих пор не имеет полной поддержки асинхронности: нет нативного асинхронного файлового ввода-вывода, ORM не поддерживает async, а для интеграции синхронных и асинхронных функций требуется постоянно писать sync_to_async и async_to_sync. Даже крупные компании вроде PostHog, несмотря на наличие AI-фич, продолжают использовать традиционный WSGI вместо полного перехода на асинхронность. В итоге команда пришла к выводу, что Django скоро начнет создавать проблемы с производительностью даже при небольшом количестве пользователей.

• Обсуждение в основном вращается вокруг того, что Python/async-экосистема остаётся незрелой, а Django-ORM не предназначена для асинхронной работы, что делает выбор между «старым, но проверенным» и «новым, но сырым» неоднозначным.
• Участники спорят, стоит ли жертвовать удобством разработки и экосистемой ради производительности, или же лучше переписать всё на Node/TypeScript, если речь идёт о высоконагруженном REST API.
• Поднимается вопрос о том, что выбор стека влияет на набор инженеров, и что важнее — удобство разработки или производительность.
• Некоторые участники подчеркивают, что важно не только выбрать правильный инструмент, но и уметь его использовать, иначе даже самый современный фреймворк не спасёт от проблем с масштабированием.

• Разнообразие технологий охватывает от классических стеков (Java/Spring, C++, Python) до современных стеков (TypeScript, Next.js, Rust, Go) и специализированных инструментов (Unity, Unreal, embedded, data engineering, QA, low-code, etc.)
• Участники демонстрируют глобальный охват: от США и Канады до Европы, Азии, Австралии и Латинской Америки, что подчеркивает международный характер рынка.
• Почти все открыты к удаленной работе, но при этом большинство не готовы к релокации, что подчеркивает гибкость и предпочтение к удаленной работе.
• Некоторые участники подчеркивают свою готовность к релокации, особенно внутри США или в крупных технологических центрах.
• Некоторые участники подчеркивают свою готовность к релокации внутри ЕС или в Северной Америке, что может быть важно для компаний, которые ищут таланты в этих регионах.

В 2025 году обновился инструмент ucs-detect для проверки поддержки Unicode в эмуляторах терминалов, теперь тестирующий DEC Private Modes, sixel-графику, размер пикселей и версию ПО. Методика проверки основана на отправке видимого текста с последующими управляющими последовательностями для определения позиции курсора, с сравнением результатов со стандартом Python wcwidth. Основная проблема эмуляторов — корректное отображение широкого спектра Unicode-символов в фиксированной сетке без нарушения читаемости.

Лидером тестов стал новый эмулятор Ghostty, разработанный с нуля на языке Zig и показавший наилучшую поддержку Unicode. Почти не уступил ему Kitty, реализовавший алгоритм разбиения текста, близкий к спецификации Python wcwidth. Оба эмулятора корректно поддерживают Variation Selector 15. Среди неожиданных результатов — низкая производительность: iTerm2 и Extraterм потребляли чрезмерное количество CPU, а GNOME Terminal на базе VTE работал более 5 часов. Полные результаты доступны на сайте проекта.

• Терминалы варьируются от полной поддержки Unicode до полного отсутствия поддержки, что делает выбор сложным, особенно для пользователей, которым важна поддержка Unicode.
• Некоторые эмуляторы, такие как Konsole, поддерживают широкий спектр Unicode, в то время как другие могут не поддерживать даже базовые символы.
• Пользователи, которым важна поддержка Unicode, должны тщательно выбирать терминал, так как не все эмуляторы поддерживают Unicode.
• Поддержка Unicode в терминалах может варьироваться от полной поддержки до полного отсутствия поддержки, что делает выбор сложным для пользователей, которым важна поддержка Unicode.

Автор столкнулся с проблемой голубей, загрязняющих его балкон. После исследования традиционных методов отпугивания (пластиковые вороны, отражатели, ультразвук и т.д.), он обнаружил, что все они неэффективны, так как голуби быстро привыкают к ним. Даже незаконная стрельба или установка кошки не представлялись жизнеспособными решениями.

Вместо этого автор создал автоматизированную систему из водяного пистолета, старого iPhone 6S в качестве камеры и микроконтроллера Wemos D1 Mini с WiFi. Python-скрипт с использованием openCV анализирует изображения с камеры и при обнаружении голубей активирует пистолет через интернет. Это гуманное решение, которое не вредит голубям, не требует постоянного присутствия автора и не портит внешний вид балкона.

Система была собрана из доступных компонентов: дешевый водяной пистолет с Amazon, 3D-напечатанный держатель для камеры и микроконтроллер с реле для управления питанием. Автор создал простое устройство для управления питанием пистолета, что позволило использовать внешнюю батарею. Камера была установлена с учетом приватности соседей, а алгоритм сравнивает текущее изображение с фоном и активирует распыление при превышении порога изменения пикселей.

• Пользователь содержит голубя Теодора на балконе, выгуливая его утром и забирая вечером.
• Предлагаемые решения: натянуть леску на перилах для отпугивания, использовать кошек или ворон, кормить голубей в другом месте.
• Технические проекты: автоматизированная система с водой и камерой, детекция голубей через OpenCV/YOLO.
• Споры о кормлении: одни считают это вредным (размножение, зависимость), другие — приятным.

• Python-оптимизация часто сводится к выносу «горячих» участков в C/NumPy, а не к микро-оптимизации кода.
• Сам факт, что в CPython «всё является объектом» влечёт за собой неизбежные накладные расходы, которые нельзя убрать без отказа от части философии языка.
• JIT (PyPy) и отсутствие GIL в будущем могут решить 90 % проблем производительности, но это не касается CPython.
• Сообщество в целом согласно с тем, что вместо попыток «оптимизировать» Python-стильный код, стоит либо полностью переписать узкие места на C/Rust, либо вовсе перейти на Julia/Go.

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

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

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

Автор обнаружил, что AI-скраперы запрашивают закомментированные JavaScript-файлы с его сайтов, вызывая ошибки 404. Эти запросы исходили как от явно вредоносных ботов (python-httpx, Go-http-client), так и от пользовательских агентов,伪装ившихся под обычные браузеры (Firefox, Chrome, Safari). Похоже, скраперы пытаются нелегально собирать контент для обучения больших языковых моделей.

Автор предлагает два возможных объяснения поведения: либо боты правильно парсят HTML-комментарии в поисках отключенных URL, либо используют примитивные методы сопоставления шаблонов. Он отмечает, что скраперы различаются по уровню сложности — одни используют актуальные строки user-agent, другие даже не меняют значения по умолчанию в HTTP-библиотеках.

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

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

SPy — это интерпретатор и компилятор для статически типизированного варианта Python с фокусом на производительность. Важно понимать, что SPy не является компилятором для полного Python — по дизайну он не поддерживает все динамические возможности языка. Код SPy будет находиться в файлах с расширением *.spy для четкого отличия от обычного Python. Хотя проект находится в разработке и пока не готов для серьезного использования, уже существует пример трассировки лучей, работающий в 200 раз быстрее CPython. SPy стремится к тесной интеграции с экосистемой Python, позволяя импортировать Python-библиотеки и наоборот.

Существующие подходы к ускорению Python делятся на две категории: реализация "полного Python" с JIT-компиляторами (PyPy, GraalPy, Pyston) и создание "подмножества Python" (Cython, Numba). SPy позиционируется как мысленный эксперимент, направленный на определение того, сколько динамичности можно удалить из Python, сохранив его "питоничность". Автор подчеркивает, что большинство "компиляторов для Python" не поддерживают полный язык, даже если заявляют обратное, и предпочитает быть более открытым о ограничениях SPy.

• Обсуждение вращается вокруг того, что статически-типизированный подмножество Python (SPy) может быть полезным, но вызывает вопросы о совместимости, экосистеме и цели проекта.
• Участники обсуждают, что неясно, как SPy будет взаимодействовать с существующими библиотеками Python, и что это значит для пользователей.
• Также обсуждается, что статическая типизация может не подходить для всех задач, и что динамическая природа Python может быть важной для некоторых задач.
• Некоторые участники высказывают, что вместо того, чтобы создавать новый язык, было бы лучше улучшить существующие инструменты, такие как Cython или Numba.

Инструмент uv, созданный компанией Astral, представляет собой революционное решение для управления Python-проектами, которое, по мнению автора, является лучшим событием в экосистеме Python за последнее десятилетие. Написанный на Rust, он обеспечивает поразительную скорость работы и объединяет в себе установку Python-версий, управление пакетами, создание виртуальных сред и быстрое разрешение конфликтов зависимостей.

Установка uv осуществляется через простую однострочную команду для Linux/Mac или Windows, и она не затрагивает существующие Python-установки. Основной рабочий процесс включает использование uv init для создания нового проекта с файлом pyproject.toml, uv sync для настройки окружения с зависимостями, и uv run для выполнения команд в правильном виртуальном окружении. Команда uv add позволяет легко добавлять пакеты с указанием версий, а uv python pin фиксирует конкретную версию Python для проекта.

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

• uv и его команда Astral продвинули экосистему Python вперёд, но вызывают вопросы о монополизации и коммерциализации.
• uv делает многое, но не всё: он не решает проблему CUDA-версий, не умеет в conda-эквивалент conda list --explicit, и не может быть установлен безопасно, если вы не используете pip install uv.
• Некоторые пользователи всё ещё предпочитают pip/venv, особенно в контексте Docker и CI, где uv может быть нестабилен.
• Но для многих разработчиков, особенно в ML и data science, uv стал незаменимым инструментом, который делает их жизнь проще.

Представлен Pipelex - новый open-source язык, созданный специально для AI агентов с целью разработки и выполнения повторяющихся AI рабочих процессов. Проект призван упростить создание сложных автоматизированных систем с использованием искусственного интеллекта, предоставляя разработчикам специализированный инструмент для реализации своих идей.

На данный момент репозиторий предлагает базовую структуру проекта, но подробная документация и примеры использования еще не полностью раскрыты. Цель разработчиков - создать гибкую платформу, которая позволит эффективно соединять различные AI сервисы и модели в единую рабочую среду, снижая порог входа для создания сложных AI-ориентированных приложений.

• Declarative workflow DSL (Pipelex) позволяет описывать пайплайны на высоком уровне, что делает его более читаемым и удобным для совместной работы между техническими и нетехническими участниками.
• В отличие от BAML, Pipelex фокусируется на том, чтобы предоставить DSL для описания логики, а не только для LLM вызовов.
• Пользователи могут запускать пайплайны как локально через CLI, так и удалённо через API сервер, который также доступен как Docker образ.
• Поддержка MCP серверов в разработке, но уже сейчас можно использовать PipeFunc для вызова любых Python функций и инструментов.
• Сообщество приветствует вклад в развитии и интеграцию с другими инструментами и сервисами.

Проект vivier/phomemo-tools представляет собой CUPS драйвер для принтера этикеток Phomemo M02, позволяющий интегрировать это устройство в Unix-подобные операционные системы. CUPS (Common Unix Printing System) - стандартная система печати для Linux и macOS, и этот драйвер расширяет её возможности, добавляя поддержку доступного портативного принтера этикеток. Это решение особенно ценно для автоматизации печати наклеек в домашних или небольших офисных условиях, где требуется маркировка товаров, файлов или других предметов.

Драйвер поддерживает печать через USB-соединение и включает в себя утилиты для управления принтером из командной строки. Проект с открытым исходным кодом позволяет пользователям вносить изменения и адаптировать функционал под свои нужды. Для установки драйвера требуется наличие Python и нескольких зависимостей, что делает его доступным для большинства современных Linux-систем. Это решение значительно упрощает использование бюджетного принтера в профессиональной среде без необходимости поиска проприетарного программного обеспечения.

Agh, I got myself a Niimbot D110 because it seemed to be the best supported "cheap" label printer (using the excellent https://niim.blue/ website).If I knew these printers had CUPS drivers I might have gone that way instead.. Is there a device you can recommend for printing (stic

Python Software Foundation (PSF) withdrew its $1.5 million grant application to the US National Science Foundation (NSF) after the agency demanded a commitment to abandon diversity, equity, and inclusion (DEI) initiatives. The proposed funding aimed to enhance security for Python's package repository PyPI by developing automated tools to proactively detect malicious code in packages, a significant improvement over current reactive methods. The NSF's condition required the PSF to affirm it would not "advance or promote DEI," a restriction applying to all PSF activities, not just the funded project. Violation would trigger the NSF to reclaim previously awarded funds, creating substantial financial risk.

This demand directly conflicted with the PSF's core mission, explicitly stating its commitment to supporting "a diverse and international community." Despite the grant's potential to significantly boost the PSF's annual $5 million budget and develop security tools with broader open-source ecosystem benefits (like NPM and Crates.io), the organization refused to compromise its values. The PSF Board unanimously decided withdrawal was necessary to retain the freedom to support its entire community. The loss of this funding, coupled with economic pressures, increases the PSF's need for direct community financial support.

• PSF отказалась от $1,5 млн гранта из-за требования отказаться от DEI-программ, что вызвало широкий резонанс в сообществе.
• Обсуждение подняло вопрос о том, что DEI-программы могут быть незаконны, и что это может быть причиной, по которой грант был отклонен.
• Некоторые участники обсуждения выразили обеспокоенность тем, что отказ от гранта может повлиять на безопасность и стабильность экосистемы Python.
• Были высказаны предложения о том, что сообщество могло бы само финансировать нужды, чтобы не зависеть от грантов с политическими условиями.
• Обсуждение также затронуло вопрос о том, что DEI-программы могут быть незаконны, и что это может быть причиной, по которой грант был отклонен.

Tenacity — это удобный кроссплатформенный многофункциональный аудиоредактор и рекордер с открытым исходным кодом, разработанный добровольцами для Windows, Linux и других ОС. Программа поддерживает запись с аудиоустройств, работу с широким спектром форматов (расширяемых через FFmpeg), включая высококачественный 32-битный float audio. Среди ключевых возможностей — поддержка плагинов VST, LV2 и AU, скриптинг на Nyquist, Python и Perl, а также продвинутые инструменты редактирования с произвольной дискретизацией и мультидорожечной временной шкалой.

Особое внимание уделено доступности: редактирование с клавиатуры, поддержка скринридеров и голосовое сопровождение. Для получения помощи сообщество активно использует Matrix-канал #tenacity2:matrix.org, а также присутствует в Mastodon и Lemmy. Развернутые версии доступны на странице релизов на Codeberg, где находится основной репозиторий проекта, хотя существует зеркало на GitHub для удобства и CI.

• Tenacity — форк Audacity, созданный из-за добавления телеметрии и новой политики конфиденциальности в основной проект.
• Причины разделения подробно описаны на официальном сайте Tenacity: https://tenacityaudio.org/docs/_content/Introduction_and_Mot...
• Ранее обсуждение на Hacker News: https://news.ycombinator.com/item?id=34835200
• Исправлена сломанная legacy-ссылка: https://tenacityaudio.org/legacy/legacy.html
• Источник исправления — Codeberg и обсуждение на IRC.

Разработчик создал неофициальную реализацию Microsoft Recall для Linux, позволяющую автоматически записывать действия пользователя для последующего поиска. Проект использует Wayland для захвата экрана и работает в средах GNOME и KDE Plasma, сохраняя данные локально в базе SQLite. Интерфейс поиска позволяет находить нужные моменты по текстовому запросу, аналогично оригинальной функции Windows.

Ключевое отличие — полное локальное хранение данных без отправки в облако, что повышает приватность. Реализация использует Python и GTK4, поддерживает фильтрацию по приложениям и временным промежуткам. Проект находится на ранней стадии разработки, но уже демонстрирует основной функционал Recall. Разработчик отмечает, что это экспериментальный проект, не связанный с Microsoft.

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

Предоставленный контент не содержит полной статьи о JupyterGIS, а представляет собой навигационную страницу European Space Agency (ESA) с информацией об их инициативе "eo science for society". На странице перечислены различные разделы, включая возможности, платформы, инструменты, сообщества и конкретные инициативы, такие как региональные проекты (Альпы, Атлантика, Балтика, Средиземноморье), программа стипендий "Living Planet" и инициатива "EO AFRICA". Также анонсированы предстоящие мероприятия, включая семинар по планированию научных исследований в Антарктике в ноябре 2025 года и конференцию по изучению океанского углерода из космоса. Для получения полного пересказа статьи о JupyterGIS необходим доступ к её основному содержанию.

• JupyterGIS предлагает интерактивную среду, где можно работать с геоданными в браузере без установки ПО, но при этом остаётся вопрос, где сохраняются изменения и как работает совместное редактирование.
• Пользователи обсуждают, какие именно возможности совместной работы реализованы в JupyterGIS и как они взаимодействуют с такими источниками данных как OpenStreetMap.
• Обсуждается, что JupyterGIS использует OpenLayers в качестве визуального бэкенда и может использовать GPU-ускорение, но при этом неясно, какие именно форматы данных он может обрабатывать и как он взаимодействует с другими инструментами Python-экосистемы.

Статья представляет собой воображаемый список курсов компьютерных наук, которых не существует, но должны. Автор предлагает такие курсы, как "Отказ от объектно-ориентированного программирования", где студенты изучат переменные вне иерархии объектов и "функции", а также "Классические исследования программного обеспечения", посвященные исторически значимым продуктам вроде VisiCalc и Zork. Особый интерес представляет курс "Написание быстрого кода на медленных языках", где учат писать на Python, который по производительности может превзойти C++, и "Пользовательский опыт командной строки", анализирующий принципы UX для консольных программ.

Автор Джеймс Хейг, бывший программист, проектирующий видеоигры с 1980-х, подчеркивает, что программирование — это не технология ради самой технологии, а возможность реализации идей. Он также предлагает курс "Одобрения программистского ума", изучающий навязчивые темы, которыми часто увлекаются разработчики: форматирование кода, таксономия, системы типов и чрезмерное дробление проектов.

• Обсуждение показало, что академическая программа CS часто не охватывает такие темы, как история ПО, философия вычислений, практика командной работы и даже базовые навыки работы в консоли.
• Участники подчеркнули, что курсы вроде "Unlearning OOP" и "Classical Software Studies" должны быть обязательной частью образования, но их нет.
• Обсуждение подняло вопрос о том, что не хватает курсов по фундаментальным навыкам, таким как CI/CD, системное администрирование и работа с консолью.
• Было отмечено, что студенты часто не получают практических навыков, необходимых для работы в отрасли, и что курсы по таким темам как "как писать быстрый код на медленных языках" или "как не страдать от внутренних конфликтов в команде" отсутствуют.
• В конце концов, обсуждение подтолкнуло к тому, что вместо того, чтобы учить студентов тому, как создавать и поддерживать сложные системы, которые уже работают, они вместо этого вынуждены изучать фреймворки, которые могут исчезнуть через 5 лет.

Саймон Уиллисон на встрече Claude Code Anonymous в Сан-Франциско рассказал о дилемме между огромной пользой от запуска кодогенерирующих агентов с минимальными ограничениями и сопутствующими рисками. Он представил флаг --dangerously-skip-permissions (или "YOLO mode"), который, по его словам, превращает Claude Code в совершенно другой продукт. В обычном режиме требуется постоянное внимание и подтверждение действий, а в YOLO-режиме агент может самостоятельно решать сложные задачи, пока пользователь занимается другими делами.

За последние 48 часов Уиллисон с помощью YOLO-режима выполнил три проекта: развернул DeepSeek-OCR на NVIDIA Spark за 40 минут, создал демонстрацию работы Pyodide в Node.js для выполнения Python-кода в WebAssembly, и разработал инструмент для анализа репозиториев с помощью SLOCCount. Он подчеркнул, что многие недооценивают ценность кодогенерирующих агентов, никогда не испытав YOLO-режим во всей его мощи, но при этом выразил обеспокоенность потенциальными рисками предоставления ИИ таких широких полномочий.

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

Проект k7 представляет собой самохостинговую инфраструктуру для создания легковесных виртуальных машин в песочницах, предназначенную для безопасного выполнения ненадежного кода. Решение предлагает полный набор инструментов: CLI для управления, API для интеграции и Python SDK для разработчиков, что делает его универсальным решением для изоляции потенциально опасного кода.

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

• Проект Katakate использует Kata Containers и Firecracker для обеспечения изоляции, но это требует аппаратной виртуализации и может не подходить для всех пользователей.
• Проект не имеет бизнес-модели и остается полностью open-source, что вызывает вопросы о его устойчивости и развитии.
• Сравнение с другими решениями, такими как gVisor и E2B, показывает, что Katakate предлагает уникальное сочетание Kubernetes, Kata и Firecracker, но это может быть неудобно для пользователей, привыкших к другим инструментам.
• Пользователи выразили обеспокоенность о том, как Katakate справляется с такими вещами, как безопасность, масштабируемость и удобство использования, особенно в сравнении с другими решениями.
• Вопросы о том, как Katakate справляется с такими вещами, как изоляция, безопасность и масштабируемость, остаются открытыми, и сообщество ждет ответов.

• Обсуждение в основном вращается вокруг проблемы установки и совместимости PyTorch/CUDA, причем участники отмечают, что «просто поставить pip install torch» редко работает из-за несовпадающих бинарников и отсутствия удобного менеджера зависимостей.
• Несколько участников подчеркивают, что NVIDIA, будучи вендором и железа и драйверов, предоставляет довольно устаревшие сборки PyTorch, что вызывает трудности даже при попытке запустить тестовый «hello world» на свежей ОС.
• Участники также обсуждают, что вместо того, чтобы тратить время на «собирание» PyTorch, можно было бы просто взять готовый wheel-файл, который бы с большей вероятностью был бы совместим с готовой CUDA-версией.
• Некоторые комментаторы также упоминают, что вместо того, чтобы тратить время на «сборку» PyTorch, можно было бы просто взять готовый wheel-файл, который бы с большей вероятностью был бы совместим с готовой CUDA-версией.

Python 3.14 представляет значительный прорыв для многопоточного Python, так как его "free-threaded" вариант достиг фазы II и больше не считается экспериментальным. Производительность улучшилась с 35% штрафом до всего 5-10%, а реализация теперь использует адаптивный интерпретатор без обходных решений из Python 3.13. Автор, разработчик веб-фреймворка и веб-сервера, провел сравнительное тестирование для веб-приложений, так как большинство существующих сервисов являются I/O-bound, а многопоточность критически важна.

Для тестирования были созданы ASGI-приложение на FastAPI и WSGI-приложение на Flask, каждый с двумя конечными точками: генератором JSON и имитацией I/O-операции с задержкой 10мс. Использовался сервер Granian, который работает с потоками вместо процессов, и инструмент rewrk для нагрузки. Цель - определить, можно ли наконец отказаться от гигабайтов памяти, тратимых на multiprocessing для параллельной обработки запросов в веб-сервисах.

• Появление free-threading в 3.13-3.14 сделало C-расширения, не обновлённые под free-threading, небезопасными и требует их обновления.
• Сообщество обсуждает, что отсутствие GIL в 3.14 может привести к тому, что старые библиотеки будут вести себя непредсказуемо, и предлагает, чтобы CPython поставлял инструмент для сканирования и обновления кода.
• Участники обсуждают, что влияние free-threading на производительность варьируется от «ничего не изменилось» до «значительно лучше» в зависимости от IO vs CPU bound кода, и что влияние на реальные приложения будет варьироваться от «ничего» до «значительно лучше».

Flowistry - это плагин для IDE, разработанный специально для языка программирования Rust. Его основная функция - помочь разработчикам сосредоточиться на релевантном коде, упрощая навигацию и понимание сложных проектов. Плагин использует статический анализ для определения связей между различными частями кода, что позволяет быстро понять, как разные компоненты взаимодействуют друг с другом.

Проект создан разработчиком Will Crichton и доступен на GitHub. Flowistry стремится решить распространенную проблему в больших кодовых базах - необходимость просматривать множество несвязанного кода для понимания контекста. Плагин предоставляет инструменты для визуализации зависимостей и определения путей данных в программе, что значительно ускоряет процесс отладки и рефакторинга кода на Rust.

• Инструмент Flowistry показывает, как данные течут в коде, но требует MIR и работает только с Rust.
• Обсуждение развилось вокруг того, почему это нельзя сделать для других языков и почему это не входит в rust-analyzer.
• Некоторые участники выразили желание увидеть подобные визуализации для TypeScript, C#, Python и других языков.
• Обсуждались вопросы товарного знака VSCode и ограничений, которые накладывает набор инструментов на то, что можно включить в IDE.
• Участники также обсудили, какие еще инструменты могли бы помочь в понимании кода и какие еще есть инструменты для других языков.

Разработчики представили Hyperflask — новый фреймворк для Python, который объединяет множество инструментов в единую экосистему для ускорения разработки веб-приложений. Основная идея в том, чтобы избавить разработчиков от необходимости самостоятельно подбирать и настраивать различные технологии, которые часто требуются в проектах.

Hyperflask включает в себя множество готовых решений: от серверной логики на Flask до фронтенд-компонентов, маршрутизации, работы с формами и данными, а также инструментов для развертывания. Все компоненты тщательно подобраны для бесшовной совместной работы. Например, вместо самостоятельной настройки Flask с десятками расширений, разработчики получают единую среду, где всё "просто работает".

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

• Единая структура проекта: стандартизированная организация кода, что ускоряет onboarding новых разработчиков и упрощает поддержку.
• Готовые решения для типовых задач: аутентификация, отправка email, обработка файлов, фоновые задачи — всё доступно "из коробки".
• Гибридный рендеринг: статические страницы генерируются на сервере для скорости, но при необходимости могут динамически обновляться через HTMX.
• Оптимизация под SEO: серверный рендеринг гарантирует, что контент индексируется поисковыми системами.

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

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

Для сообщества это может быть значимым, поскольку экосистема Python долгое время не имела полноценного аналога популярным JavaScript-фреймворкам вроде Next.js. Hyperflask, хоть и молодой проект, показывает важный шаг в этом направлении.

• Обсуждение в основном вращается вокруг сравнения Flask/HTMX-стека с альтернативами (FastAPI, Django, Litestar, FastHTML), где критика касается производительности, архитектуры и "state of the art" в 2025 году.
• Участники спорят о целесообразности смешивания шаблонов и логики в одном файле, о том, насколько это упрощает или усложняет разработку, и о том, как это сказывается на тестируемости и сопровождении кода.
• Ряд комментаторов поднимает вопрос о том, что выбор Flask в 2025 году может быть устарел, особенно если учесть отсутствие встроенной поддержки async/await, и сравнивает его с FastAPI или Litestar.
• Некоторые участники высказывают мнение, что вместо того, чтобы изобретать еще один каркас, было бы лучше взять существующий и внедрить в него улучшенную документацию, инструменты и лучшие практики.

Инструмент modshim позволяет переопределять и настраивать Python-пакеты без изменения их исходного кода. Это решение даёт возможность вносить изменения в зависимости, исправлять ошибки или добавлять функциональность без создания форка проекта. Подобные инструменты часто используют техники перехвата импорта или патчирования модулей во время выполнения.

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

• Пользователи обсуждают инструмент для monkey-patching в Python, который использует временный импорт-хук для обхода импортов и позволяет документировать код в стиле literate-code.
• Некоторые участники отмечают, что такой подход может быть неудобен при работе с внешними зависимостями, особенно если они часто обновляются, и что это может привести к необходимости поддерживать форк.
• Участники также обсуждают, что вместо использования такого инструмента, можно было бы просто форкнуть библиотеку и внести изменения, что может быть более устойчивым решением в долгосрочной перспективе.
• Также поднимается вопрос о том, что если библиотека, которую вы хотите изменить, имеет сложную систему импортов и экспортов, то такой инструмент может не справиться с этим.
• В конце обсуждение сместилось в сторону обсуждения того, что если вы контролируете все импорты, то вы можете просто сделать сабкласс или обвернуть нужные части библиотеки, что может быть более питоничным способом решения проблемы.

Kaitai Struct — декларативный язык для описания и разбора бинарных форматов, позволяющий определить структуру данных один раз, а затем использовать это описание в различных языках программирования. Поддерживается 12 языков, включая C++, Java, Python, JavaScript и Rust, что делает его универсальным инструментом для работы с бинарными файлами и сетевыми протоколами. Проект бесплатный и открытый, включает компилятор, веб-IDE, визуизатор и обширную библиотеку популярных форматов.

Система работает через описание формата в файле .ksy, который компилируется в исходный код выбранного языка. Например, простое описание заголовка GIF позволяет получить доступ к таким полям, как ширина и высота изображения через удобный API. Такой подход устраняет необходимость в написании повторяющегося, подверженного ошибкам кода для разбора бинарных структур, экономя время и упрощая отладку.

• Kaitai Struct — декларативный язык описания бинарных форматов, который генерирует код на разных языках.
• Пользователи отмечают, что он удобен как для работы, так и для хобби-RE, но жалуются на отсутствие поддержки записи и громоздкий YAML.
• Появилась экспериментальная поддержка сериализации в Python и Java, но она пока не покрывает все типы полей и требует ручной работы.
• Сравнение с Wuffs и Construct показывает, что Kaitai фокусируется на описании форматов, тогда как Wuffs — на безопасном коде, а Construct — на удобстве использования.
• Сообщество обсуждает, что нехватка поддержки других языков (Rust, Zig) и отсутствие поддержки полного цикла чтение-изменение-запись делает Kaitai менее универсальным, чем можно было бы.

Meta представила Pyrefly — новый статический анализатор для Python, способный проверять до 1,85 млн строк кода в секунду. Он работает в 10 раз быстрее, чем основные конкуренты, такие как Pyright и MyPy, при этом сохраняя высокую точность.

Pyrefly интегрируется как сервер языка (LSP) для VS Code и других редакторов, предлагая автодополнение, подсветку ошибок и навигацию по коду. Инструмент уже протестирован на крупных проектах, включая код PyTorch.

Разработчики подчеркивают, что Pyrefly не требует аннотаций для старта, но улучшает качество кода при их использовании. Инструмент доступен как open-source и поддерживается через Discord-сообщество.

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rr rrrr

Новый язык программирования стоит создавать, если он позволяет выразить идеи или концепции, которые невозможно или неудобно описывать в существующих языках. Это не просто вопрос синтаксиса или семантики, но и всей экосистемы, включающей библиотеки, инструменты и сообщества. Например, Python ценят за богатство библиотек, делающих его универсальным, а Go — за простую модель параллелизма. Таким образом, язык программирования определяется синтаксисом, семантикой и экосистемой, которые вместе открывают новые направления для исследования и творчества. Создавайте смелые, даже непрактичные языки, чтобы исследовать неизведанное, а не просто решать известные задачи.

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

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

В Linux они передаются через execve как массив строк вида KEY=VALUE. Внутри процесса они хранятся в стеке или куче, а программы используют разные структуры данных для их представления: Bash использует хешмапы, Python — словари, а C — массив environ.

Важно помнить, что изменения в дочернем процессе не влияют на родительский, и не все инструменты наследуют окружение. Например, login задаёт свежее окружение.

Из-за отсутствия пространств имён или типов легко допустить ошибку, например, перезаписать критичную переменную PATH. Хотя они удобны для конфигурации, их следует использовать с осторожностью.

• Обсуждение охватило широкий спектр тем: от безопасности переменных окружения до передачи секретов, влияния на разные системы и стандарты, и даже до влияния на разработку программного обеспечения.
• Участники обсуждали, что переменные окружения небезопасны для передачи секретов, так как любой процесс может прочитать их.
• Были упомянуты альтернативы, такие как systemd-creds, которые могут быть использованы для передачи секретов безопасно.
• Также обсуждались проблемы с конфигурацией и стандартами, такие как использование переменных окружения для конфигурации вместо файлов конфигурации.
• Участники также обсуждали влияние переменных окружения на разработку программного обеспечения, включая влияние на разработку в Windows и Unix системах.

Andrej Karpathy запустил NanoChat, проект, позволяющий запускать мощные чат-модели ИИ на недорогих локальных устройствах, таких как Raspberry Pi. NanoChat использует эффективные методы для работы на устройствах с ограниченными ресурсами, не требуя мощного сервера или облачных сервисов. Это открывает возможности для разработчиков и любителей создавать чат-приложения с ИИ, которые работают локально, без необходимости в постоянном подключении к интернету или дорогой инфраструктуре. Проект особенно полезен для образовательных целей, прототипирования и сценариев, где важны конфиденциальность и автономность.

• Обсуждение вращается вокруг того, что Андрей Карпати (Andrej Karpathy) опубликовал репозиторий nanochat, который, по его словам, позволяет за 100 долларов обучить модель на 124M параметров за 4 часа на 8xH100.
• Участники обсуждения подчеркивают, что это не «обучение за 100$», а аренда GPU за 100$ в час, и что репозиторий в первую очередь демонстрирует, как можно обучить модель, а не предоставляет доступ к вычислительным ресурсам.
• Некоторые участники спрашивают, можно ли использовать этот репозиторий для тонкой настройки существующих моделей, и Карпати отвечает, что это возможно, но требует дополнительных усилий.
• Также обсуждается, что обучение на собственных данных может быть дороже, чем обучение на открытых данных, и что для этого потребуется большее количество вычислительных ресурсов.
• В конце обсуждение сместилось к тому, что Карпати в своих видео и твитах продолжает вдохновлять людей изучать и развивать свои проекты, и что его вклад в открытое образование и исследовательскую свободу важен.

В статье обсуждается, что главная проблема конфигурационных файлов — не синтаксис, а отсутствие абстракций. Хотя многие ругают YAML за сложность, реальная проблема в том, что даже простые форматы вроде JSON не решают проблему дублирования и ошибок вроде опечаток в числовых константах.

Автор показывает на примере: если нужно описать несколько однотипных ресурсов (в примере — cloud-бакетов для бэкапов), то даже в JSON или YAML придётся дублировать код, что ведёт к ошибкам. Например, в одном месте указали 2592000 секунд (30 дней), а в другом — 259200 (пропустили ноль), и из-за этого данные удаляются через 3 дня, а не 30.

Решение — использовать язык конфигурации, который поддерживает абстракции, как в языках программирования. Например, RCL позволяет использовать переменные, циклы и вычисления, что исключает ошибки из-за опечаток и дублирования. Так, вместо шести повторяющихся блоков конфигурации можно написать один цикл, который сгенерирует их все, гарантируя, что все значения согласованы.

Хотя некоторые форматы (как HCL) тоже поддерживают выражения, важно, чтобы их хватало для полного устранения дублирования. Поэтому при выборе формата конфигурации стоит смотреть не только на синтаксис, но и на возможность абстракций.

• Обсуждение в основном вращается вокруг того, что конфигурационные языки (YAML, JSON, TOML и т.д.) не масштабируются и не имеют абстракций, что приводит к необходимости встраивать в них полноценные языки программирования, что в свою очередь создает проблемы безопасности и предсказуемости.
• Участники обсуждения подчеркивают, что вместо того, чтобы изобретать новые конфигурационные языки, следует использовать существующие общеязыковые инструменты (Python, Lisp и т.д.) для конфигурации как код, что позволит избежать проблем с безопасностью и сложностью.
• Некоторые участники также упоминают, что проблема не в синтаксисе или структуре данных, а в отсутствии стандартного языкового сервера для конфигурационных файлов, что делает невозможным автодополнение и переход к определению.
• Также поднимается вопрос о том, что если конфигурационный язык предоставляет возможность встраивать код, то это может быть использовано для вредоносных целей, и вопрос о том, как обеспечить безопасность таких файлов, становится критически важным.
• В конце концов, обсуждение сходится на том, что вместо того, чтобы продолжать изобретать новые конфигурационные языки, следует использовать существующие языки программирования и инструменты, которые уже решают эти проблемы.

Команда разработчиков представила новую версию pdfly 0.5.0 — инструмента для работы с PDF, который теперь умеет подписывать документы и проверять их подписи, что повышает безопасность. Также добавлена функция извлечения страниц с аннотациями, что упрощает извлечение конкретных данных. Эти обновления делают pdfly ещё более универсальным инструментом для управления PDF-файлами.

Проект активно развивается, привлекая участников через Hacktoberfest, что демонстрирует его активное сообщество. pdfly продолжает расширять свой функционал, оставаясь ключевым инструментом в экосистеме Python для работы с PDF.

• Обсуждение показало, что существует множество инструментов для работы с PDF, но ни один из них не является универсальным решением.
• Участники обсудили, что большинство инструментов имеют ограничения в виде отсутствия поддержки Linux, несоответствия лицензии, отсутствия GUI или CLI, и т.д.
• Обсуждались такие инструменты как poppler, qpdf, pdfcpu, pdfinfo, pdfseparate, pdfimages, pdfdetach, pdftotext, pdftohtml, pdftopng, pdf2svg, pdf2htmlEX, pdf2txt, pdf2html, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2htmlEX, pdf2txt, pdf2
• Участники также обсудили, что большинство инструментов не поддерживают все возможные операции с PDF, и что каждый инструмент имеет свои ограничения и особенности.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует множество инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальным решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструментов, которые могут быть использованы для работы с PDF, но ни один из них не является универсальым решением.
• Участники также обсудили, что существует мнольство инструмент

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

MAML уже реализован в нескольких языках, включая JavaScript, Python, Rust, C и PHP. Эти реализации находятся на разных стадиях разработки: от готовых к использованию до находящихся в активной разработке.

Проект полностью открыт, с кодом на GitHub, и распространяется по лицензии MIT, что позволяет свободно использовать, модифицировать и распространять его.

• Обсуждение вновь подтвердило, что вместо улучшения JSON/YAML/TOML появляется всё больше новых конфиг-языков, но никто не решает их проблемы с синтаксисом, датами, комментариями и т.д.
• Участники обсуждения отмечают, что большинство этих новых языков не решают фундаментальные проблемы, такие как отсутствие типов данных, дат и комментариев в JSON.
• Некоторые комментаторы подчеркивают, что вместо того, чтобы изобретать новые языки, лучше бы улучшить существующие инструменты, такие как JSON5 или TOML.
• Другие участники поднимают вопрос, что если бы разработчики потратили усилия на улучшение существующих инструментов, вместо создания новых, это было бы более продуктивно.

pgEdge выпустил open-source-утилиту spock — логическую репликацию PostgreSQL с поддержкой multi-master. Проект позиционируется как замена Bucardo и Slony, но с фокусом на высокую доступность и отказоустойчивость. Под капотом — использование логической репликации, что позволяет конфликтам разрешаться на уровне транзакции, а не на уровне отдельных запросов. Это делает spock пригодным для кластеров, где каждая нода может принимать запись.

Проект написан на C и Python, распространяется под лицензией PostgreSQL. Поддерживает PostgreSQL 12-16 и требует расширение pglogical.

• Разработчики подчеркнули, что multi-master репликация не обеспечивает такую же строгую согласованность, как PostgreSQL, и что это важно учитывать при выборе решения.
• Участники обсуждали, что при использовании multi-master репликации важно понимать, какие именно edge cases могут возникнуть и как они решаются.
• Были упомянуты такие решения, как CockroachDB и pgEdge, и обсуждались их плюсы и минусы по сравнению с другими решениями.
• Также обсуждались вопросы лицензии и лицензионной политики, а также то, какие именно ограничения могут быть связаны с использованием таких решений.
• В конце обсуждения было отмечено, что важно понимать, что multi-master репликация не решает всех проблем масштабирования и что важно тщательно оценивать, подходит ли она для конкретного use case.

Разработчики часто сталкиваются с тем, что официальная документация описывает функцию, но не показывает, как её использовать. Пример: вместо того, чтобы показать, как вызывать max() в Python, документация тратит абзацы на то, чтобы объяснить, что такое iterable и что значит key=. А ведь достаточно было бы показать, как передавать кастомную функцию сортировки в max().

Проект ClojureDocs берёт на себя роль «примеры — лучшая документация». Пользователи добавляют примеры к встроенным функциям, и это оказывается куда более полезным, чем формальное описание API. Примеры показывают, как вызывать функцию, какие есть подводные камни и какие есть альтернативы.

• Документация должна включать и примеры, и полное API-описание; оба формата дополняют, а не конкурируют.
• Примеры важны для новичков, но не заменяют полное описание параметров и контрактов; примеры без спецификации приводят к тому, что разработчики вынуждены читать исходники.
• Примеры должны быть живыми: если они не запускаются как часть CI или не покрыты тестами, они быстро устаревают и вводят в заблуждение.
• Документация должна быть двух типов: краткий пример для быстрого старта и полное руководство для продвинутых пользователей.
• Примеры должны быть частью тестов и наоборот: примеры в документации должны быть тестируемыми как часть CI.

Python действительно разбивает строку не только по \n, \r и \r\n, но и по целому ряду юникод-разделителей: \x1c, \x1d, \x1e, \x85, \u2028, \u2029 и другим. Это означает, что splitlines() может разбивать строку на части там, где вы этого не ожидаете.

• Обсуждение показало, что splitlines() и split() ведут себя неодинаково, особенно в отношении обработки символов перевода строки и других пробелов.
• Участники отметили, что splitlines() может неожиданно удалять символы перевода строки, если они встречаются в конце строки, в то время как split() этого не делает.
• Также было отмечено, что split() разделяет строку по любому пробельному символу, в то время как splitlines() только по символам перевода строки.
• Несколько человек поделились личным опытом, что они узнали что-то новое из обсуждения, даже несмотря на то, что это уже было в документации.
• В целом, обсуждение подчеркнуло важность внимательного чтения документации и понимания различий между похожими, но не идентичными функциями.

Python 3.14 вышел 8 октября 2025 года. Автор сравнил его с 3.9-3.13, а также с PyPy 3.11, Node.js 24 и Rust 1.90. Для тестов использовались два скрипта: рекурсивный расчет 40-го числа Фибоначчи и пузырьковая сортировка 10 000 элементов. Все тесты запускались на ноутбуке с Intel Core i5 под Ubuntu и ноутбуке Apple M2 под macOS.

Результаты: CPython 3.14 оказался на 10-15% быстрее 3.13 и примерно вдвое быстрее 3.9. JIT в 3.14 работает стабильно, а в 3.13 еще может выдавать сбои. Free-threading в 3.14 показал себя как надежный способ распараллеливать задачи, но прирост не столь драматичен, как ожидалось. PyPy 3.11 оказался в 2-3 раза быстрее CPython 3.14, но требует в 2-3 раза больше памяти. Node.js и Rust оказались в 2-3 раза быстрее, но это сравнение не совсем корректно, так как они не тестировали рекурсию.

• Пользователи обсуждают производительность Python 3.14, сравнивая его с PyPy и другими языками, и обсуждают, почему сообщество продолжает тратить усилия на ускорение CPython вместо перехода на PyPy.
• Несколько комментаторов отмечают, что 3.14 всё ещё значительно уступает PyPy и даже Node.js в ряде тестов, хотя и демонстрирует прогресс.
• Обсуждается, почему Python не может быть переименован в π-thon, несмотря на то, что это было бы логично, и почему не используется возможность перехода на PyPy, несмотря на то, что он быстрее.
• Участники также обсуждают, что, несмотря на то, что Python всё ещё остаётся медленным, он остаётся незаменимым для прототипирования и имеет огромную экосистему библиотек, что делает его незаменимым для многих задач.
• Наконец, обсуждается, что, несмотря на то, что Python медленный, он всё ещё может быть использован для большинства задач, и что важнее всего - он всё ещё может быть использован для большинства задач.

Разработчики выпустили PyTauri — это привязка Python к фреймворку Tauri, который позволяет создавать настольные приложения с помощью веб-технологий. Теперь разработчики могут использовать Python для создания приложений, которые компилируются в нативные исполняемые файлы, сохраняя при этом все преимущества веб-разработки, такие как HTML, CSS и JavaScript. Это открывает возможности для создания кроссплатформенных приложений с меньшим весом и более высокой производительностью по сравнению с традиционными Electron-приложениями. Проект примечателен тем, что объединяет простоту Python с мощью современных веб-технологий.

• Обсуждение показало, что Tauri не является просто обёрткой над системным WebView, а скорее фреймворком, который может использовать различные движки, включая экспериментальный Servo.
• Участники обсудили, что Tauri позволяет использовать веб-технологии для создания десктоп-приложений, но при этом не требует включения полной копии Chromium в каждом приложении, как это делает Electron.
• Были упомянуты преимущества Tauri в контексте лицензий Qt и сложности использования Qt, а также вопросы производительности и размера дистрибутива.
• Участники также обсудили, что Tauri позволяет использовать Python в качестве бэкенда, что может быть полезно для веб-разработчиков, желающих использовать веб-технологии для создания десктоп-приложений.

Pdoc автоматически генерирует API-документацию для Python-проектов, сохраняя иерархию модулей. Инструмент не требует настройки, поддерживает аннотации типов, перекрёстные ссылки и понимает docstrings в стиле Google или numpydoc. Например, команда pdoc demo.py создаст документацию для класса Dog с его атрибутами и методами, включая описание name и friends.

Pdoc также включает встроенный веб-сервер с live-перезагрузкой для удобства разработки. Он популярен среди крупных проектов, таких как Google OR-Tools и Microsoft, благодаря своей простоте и точности. Практический вывод: инструмент экономит время, автоматизируя рутинную работу по документированию.

• Участники обсуждают инструменты для генерации документации Python-библиотек, выделяя pdoc за простоту использования и автоматизацию, а MkDocs с Material-темой — для более крупных проектов с расширенными возможностями.
• Поднимаются технические нюансы, такие как размещение докстрингов для переменных (ниже объявления, по аналогии с функциями) и проверка валидности ссылок между разными системами документации.
• Обсуждается баланс между лаконичными докстрингами в коде и более подробной внешней документацией, например, с помощью Sphinx.
• Упоминаются удобство интеграции pdoc с GitHub Pages и отсутствие значительного прогресса у форков проекта.
• Затрагивается тема использования общих инструментов для проверки ссылок (например, lychee) вместо специфических библиотек для pdoc.

Talk Python in Production – это книга, которая учит разворачивать Python-приложения без привязки к облачным провайдерам. Вместо микросервисов и Kubernetes автор предлагает «stack-native» подход: один мощный сервер, Docker Compose, NGINX и минимум внешних сервисов. Книга сопровождается GitHub-репозиторием с примерами кода, конфигами и скриптами CI/CD, а также готовыми Docker-образами.

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

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

Фреймворк устраняет компромисс между эффективностью формато-специфичных решений и простотой поддержки общего инструмента. В отличие от универсальных методов, которые тратят ресурсы на угадывание структуры, OpenZL заранее знает тип данных и фокусируется только на релевантных трансформациях. Это позволяет экономить вычислительные циклы и улучшать соотношение скорости к степени сжатия. Практический вывод: один бинарный инструмент может заменить множество кастомных компрессоров без потери производительности.

• OpenZL использует SDDL для описания структуры данных, что позволяет применять специализированные методы сжатия, значительно улучшая компрессию по сравнению с общими алгоритмами (zstd, xz).
• Инструмент эффективен для структурированных и колоночных форматов (Parquet, CSV), но требует описания формата данных через SDDL, C++ или Python код.
• Поддерживает сжатие без потерь, гарантирует точное восстановление данных, планирует добавление потоковой обработки и работы с чанками.
• Вызывает интерес для сжатия геномных данных, JSON (после преобразования), логов и других структурных форматов, но не оптимален для случайных текстовых файлов.
• Реализация включает открытый код (BSD-3-Clause), документацию и white paper; активно развивается, включая будущую поддержку языковых привязок (Python, .NET).

Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

Ключевое преимущество — автоматическое определение контекста и зависимостей между проектами, что сокращает рутинные операции. Интеграция с существующими инструментами вроде npm scripts делает переход плавным. Такой подход экономит время и снижает вероятность ошибок при ручном управлении задачами.

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.

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

• uv стал фактическим стандартом для управления зависимостями и окружениями, потому что он быстрый и простой в использовании, но это вызвало споры о том, действительно ли он лучше, чем pip и другие инструменты, особенно в контейнерах и CI/CD.
• Некоторые разработчики утверждают, что uv не подходит для контейнеров, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.
• Пользователи, которые привыкли к pip и другим инструментам, иногда утверждают, что uv не предоставляет никаких преимуществ, и что это просто "Rust фанатство", но другие считают, что скорость и простота использования делают его лучшим выбором.
• Некоторые разработчики считают, что uv не подходит для использования в контейнерах, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.
• Некоторые разработчики считают, что uv не подходит для использования в контейнерах, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.

Инженеры всё чаще запускают несколько агентов одновременно — например, одновременно работают несколько экземпляров Claude Code или Codex CLI в разных директориях или даже в разных репозиториях. Саймон Уиллисон, который сам пишет код на Python и JavaScript, решил проверить, насколько полезно это на практике.

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

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

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

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

• Обсуждение в основном вращается вокруг трёх тем: высокая стоимость ревью кода, параллельные агенты и их влияние на фокус и продуктивность, а также культурные и этические аспекты использования AI-агентов.
• Участники делятся личными стратегиями, такими как использование различных инструментов вроде Conductor и Crystal для управления агентами, и обсуждают, как сделать их более эффективными.
• Обсуждается, как сделать ревью кода менее трудоёмким, включая использование инструментов вроде bottleneck для ревью кода, и как влияет на продуктивность и фокус.
• Также обсуждается, как влияет на эффективность работы использование AI-агентов, и какие могут быть последствия для долгосрочной устойчивости и качества кода.

"The Debugging Book" — это учебник по автоматическому поиску и устранению дефектов в программном обеспечении. Он охватывает весь цикл: от трассировки и наблюдения за выполнением кода до автоматического ремонта кода. Книга предлагает как теорию, так и практические примеры кода на Python, которые можно запустить прямо в браузере через Jupyter.

Книга предназначена для студентов, преподавателей и разработчиков программного обеспечения. Она охватывает такие темы, как трассировка, отслеживание ошибок, их причины и автоматическое ремесленное восстановление кода. Все примеры кода доступны для запуска и изучения.

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

pyscn — это интеллектуальный анализатор качества Python-кода с открытым исходным кодом. Он использует статический анализ для выявления проблем вроде неиспользуемых переменных, избыточных конструкций и нарушений стиля, помогая разработчикам писать более чистый и эффективный код.

Инструмент предлагает детальные отчёты с рекомендациями по исправлению, интеграцию в CI/CD и поддержку кастомных правил. Особенность — акцент на объяснении ошибок, что ускоряет обучение и улучшает практики кодинга.

• Обсуждение инструмента для анализа качества кода, который использует tree edit distance на AST для обнаружения структурных дубликатов, в отличие от текстовых сравнений
• Споры о "vibe coders" (разработчиках, полагающихся на ИИ): одни считают их безразличными к качеству, другие защищают как прагматичный подход для определенных задач
• Вопросы о технических деталях: влияние языков со статическим анализом, обобщаемость на другие языки через tree-sitter, сравнение с существующими инструментами (Pylint, Ruff)
• Предложения по интеграции: как инструмент для инженеров, поддерживающих legacy-код, или как MCP-сервер для AI-агентов
• Обсуждение будущего: роль инструментов анализа в эпоху ИИ-ассистентов и их потенциал для улучшения качества в доминирующих языках (Python/JS)

Универсальный раннер и умный REPL на Rust, который автоматически определяет язык программирования по расширению файла или shebang и выполняет код без предварительной настройки. Поддерживает Python, JavaScript, Ruby, Go и другие популярные языки, экономя время на переключении между средами.

Инструмент предлагает интерактивный режим с подсветкой синтаксиса и историей команд, а также пакетную обработку файлов. Ключевое преимущество — кроссплатформенность и минимальные зависимости, поскольку написан на Rust. Практический бонус: можно быстро тестировать сниппеты, не покидая терминал.

• Автор представил инструмент run как унифицированный REPL для множества языков, позволяющий выполнять код разных языков одной командой без переключения между отдельными REPL.
• Обсуждаются технические детали и сравнение с существующими инструментами: шебанг-строка, задачами just, магическими командами IPython/Jupyter и возможностью запуска скриптов через Bash.
• Уточняется классификация языков (Swift, Kotlin) как компилируемых или интерпретируемых в контексте работы инструмента.
• Поднимается вопрос о мотивации создания инструмента и терминологии ("polyglot"), а также простоте добавления поддержки новых языков через реализацию trait на Rust.
• Автор поясняет, что инструмент — это эксперимент новичка в Rust, а не замена существующим решениям.

Предлагается добавить в Python явный синтаксис для ленивого импорта с ключевым словом lazy, которое размещается перед import или from. Это позволяет отложить загрузку модуля до момента первого использования импортированного имени, сокращая время запуска и потребление памяти. Особенно полезно для CLI-инструментов с подкомандами, где даже вызов --help может загружать десятки ненужных модулей.

Ленивые импорты сохраняют полную обратную совместимость — обычные импорты работают как раньше, а новые семантика активируется только при явном указании. Механизм использует прокси-объекты, которые заменяются реальными значениями при первом обращении (реификация). Это решает проблему ручного переноса импортов в функции, что уже делается в 17% случаев в стандартной библиотеке.

• Предложение о ленивых импортах (PEP 690) поддерживается для ускорения запуска CLI-инструментов и уменьшения накладных расходов, но вызывает опасения по поводу непредсказуемости и ошибок времени выполнения.
• Критики указывают на проблемы с безопасностью потоков, сложность отладки и потенциальное ухудшение читаемости кода из-за нового синтаксиса (lazy import).
• Альтернативы включают ленивую загрузку на уровне модуля (с явным объявлением модулем), использование существующих методов (импорт внутри функций) или инструментов вроде LazyLoader.
• Некоторые участники выступают за ленивые импорты по умолчанию, но признают, что это нарушит обратную совместимость из-за побочных эффектов при импорте.
• Обсуждаются вопросы совместимости с линтерами, влияние на стандартную библиотеку и необходимость обновления парсеров и редакторов для поддержки нового ключевого слова.

Эксперимент показал, что формат данных существенно влияет на точность понимания таблиц LLM. Лучший результат показал Markdown-KV (key-value пары в markdown) с точностью 60,7%, но он потребовал в 2,7 раза больше токенов, чем самый экономный CSV. XML и INI также показали высокую точность (56% и 55,7%), тогда как CSV и JSONL оказались наихудшими — около 44%. Это указывает на возможность улучшения RAG-пайплайнов простой сменой формата данных, хотя эффективность часто требует компромисса с количеством токенов.

• Результаты тестирования GPT-4.1-nano показали, что точность извлечения данных из таблиц варьируется от 40% до 60% в зависимости от формата, при этом Markdown-KV показал наилучший результат.
• Многие участники раскритиковали методологию исследования, указав на использование только одной, слабой модели (GPT-4.1-nano) и недостаточный размер данных для оценки влияния контекстного окна.
• Было высказано сомнение в практической целесообразности использования LLM для обработки табличных данных, учитывая доступность более точных и эффективных традиционных инструментов (например, Python-скриптов, SQL).
• В качестве альтернативы предложены агентные подходы, где LLM генерирует код (например, SQL-запросы или функции) для последующего выполнения, что показало высокую эффективность в реальных задачах.
• Обсуждались потенциально более эффективные форматы данных (XML с короткими тегами, TOML, KSON) и необходимость тестирования на более мощных моделях (GPT-5, Claude, Gemini) для получения репрезентативных результатов.

Автор перевел свой блог с Racket на Lua, чтобы снизить сложность и обеспечить долгосрочную стабильность. Основная причина — разочарование в быстро меняющихся экосистемах вроде JavaScript и Ruby, где постоянные обновления и ломающие изменения усложняют поддержку. Lua привлек медленным развитием: между версиями 5.1 (2006) и 5.4 (2020) различия минимальны, а язык требует лишь компилятора C89.

Блог работает по старинке — через CGI-скрипты, с SQLite в качестве базы и шаблонизацией Mustache. Несмотря на кажущуюся архаичность, автор ценит простоту, минимальное количество зависимостей (около десяти) и возможность писать собственные легковесные библиотеки. Ключевой вывод: блог — это пространство для экспериментов, где можно отказаться от модных инструментов в пользу того, что действительно работает и приносит удовольствие.

• Предложение возродить создание собственных движков для блогов как учебного проекта для инженеров из-за его низкого риска и возможностей для экспериментов.
• Обсуждение выбора Lua как стабильного и минималистичного языка для веб-разработки, несмотря на его недостатки (1-based индексация, разрыв между версиями, мало стандартных библиотек).
• Критика сложности современных стеков для блогов и аргументы в пользу простых решений: статические генераторы (Hugo), чистый HTML или минимальные скрипты (Python, Lua).
• Упоминание альтернативных технологий и подходов: Redbean, Perl, Caddy, XSLT, Web Components, Fennel, OpenResty и другие.
• Подчёркивание важности личного выбора, удовольствия от процесса и независимости от внешних сервисов при создании блога.

Проект playball позволяет смотреть трансляции матчей MLB прямо в терминале через ASCII-графику. Вместо видео поток передаётся текстовыми символами, имитирующими поле, игроков и мяч, что создаёт минималистичный, но на удивление детализированный опыт просмотра.

Для работы требуется аккаунт MLB.tv и настроенный доступ к их стриминговому сервису. Инструмент написан на Python, использует библиотеку curses для отрисовки интерфейса и парсит данные в реальном времени. Это интересный пример того, как ностальгический формат терминала может быть адаптирован для современных развлечений, экономя трафик и ресурсы.

• Участники обсуждают проект терминального просмотра текстовой трансляции бейсбольных матчей MLB, отмечая его удобство и связь с хакерской культурой.
• Поднимается тема доступности данных MLB через API и существования аналогичных инструментов для других видов спорта (NBA, NFL, крикет, футбол).
• Обсуждаются исторические и экономические причины снижения популярности бейсбола, а также преимущества MLB в области стриминга по сравнению с другими лигами.
• Упоминается практика ведения текстового протокола игры (scorekeeping) и то, как хорошо бейсбол подходит для текстового формата из-за своей структуры.
• Высказываются пожелания по развитию проекта, включая анимацию, поддержку других лиг и

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

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

• Критика выбора Python как основного языка для библиотеки из-за проблем с производительностью, ошибками и сложностью работы с типами.
• Негативная реакция на название "Newton Physics" из-за возможной путаницы с существующим движком Newton Dynamics и воспринимаемой arrogance авторов.
• Обсуждение технических деталей: использование MuJoCo как бэкенда, запись в CUDA graph для производительности, параллелизация множества сред для reinforcement learning.
• Сравнение с PhysX и мнение, что Newton Physics со временем его заменит, будучи более настраиваемым и расширяемым.
• Замечания о недостатках примеров кода, которые слишком высокоуровневы и не демонстрируют реальные преимущества и сложности использования API.

• Компании ищут инженеров для работы с AI/ML, включая роли Senior Machine Learning Engineer, ML Scientist и разработчиков для создания AI-инструментов в различных областях, таких как биология, недвижимость и безопасность.
• Предлагаются позиции в software development, включая Full Stack, Backend, Frontend и MLOps инженеров, с использованием технологий Python, Kotlin, TypeScript, Rust и других, для удаленной, гибридной или офисной работы.
• Есть вакансии в сфере облачных технологий и инфраструктуры, такие как Cloud Engineer, SRE и DevOps, с фокусом на AWS, GCP, Azure и управление масштабируемыми системами.
• Несколько ролей связаны с разработкой в нишевых областях: квантовые вычисления, 3D-моделирование, финансовые технологии (алготрейдинг), видеоигры и управление цепочками поставок.
• Предложения включают позиции разного уровня, от начинающих до ведущих инженеров и архитекторов, с вариантами визовой поддержки, релокации и конкурентными зарплатами в диапазоне от $120k до $240k+ в зависимости от опыта и локации.

• Разработчики ищут удалённую работу, многие открыты к релокации, предпочитают гибридный формат или готовы к редким командировкам.
• Основные технологические стеки включают Python, JavaScript/TypeScript, React, Node.js, облачные платформы (AWS, GCP) и контейнеризацию (Docker, Kubernetes).
• Специализации варьируются от full-stack, data engineering и машинного обучения до дизайна продуктов и UX/UI.
• Ключевые интересы: работа с LLM, AI-агентами, компьютерным зрением, распределёнными системами и дизайн-системами.
• Многие кандидаты имеют опыт более 10 лет, опыт построения масштабируемых продуктов и решения сложных бизнес-задач.

После многолетнего активного использования Julia для анализа данных и разработки пакетов автор перестал рекомендовать язык из-за серьёзных проблем с корректностью и композируемостью. В экосистеме Julia наблюдается высокая частота критических ошибок, которые проявляются даже в базовых операциях: например, функции sum! и prod! иногда молча возвращают неверные результаты, а выборка из распределений может давать смещённые или некорректные значения.

Особенно уязвимы комбинации пакетов или нестандартные типы данных — Euclidean Distance не работает с векторами Unitful, а макрос @distributed ломается при использовании OffsetArrays. Многие ошибки приводят к выходу за границы памяти или тихим неверным вычислениям, что ставит под сомнение надёжность любых сложных расчётов. Практический вывод: в проектах, где важна точность, Julia может представлять неприемлемый риск.

• Участники обсуждают проблемы с корректностью и стабильностью экосистемы Julia, включая критические баги в базовых пакетах и проблемы совместимости.
• Высказываются опасения, что эти проблемы делают язык неподходящим для проектов, где важна точность, несмотря на его элегантность и производительность.
• В качестве альтернатив для научных вычислений упоминаются Python с библиотеками (PyTorch, Jax, TensorFlow), R (и tidyverse), а также Rust и Go.
• Некоторые пользователи делятся негативным опытом из-за невыполненных обещаний (например, быстрая компиляция) и переходят на другие языки.
• Обсуждается актуальность критики, поскольку некоторые примеры проблем датируются 2024 годом, несмотря на то, что исходный пост мог быть написан ранее.

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

Ключевые особенности включают многоканальные пайпы (multipipes) для связи команд с несколькими входами и выходами, блоки {{ ... }} для асинхронного выполнения процессов и хранение значений (stored values) для обмена данными между произвольными узлами графа. Примеры использования охватывают бенчмарки сжатия, анализ кода, поиск дубликатов и обработку научных данных, демонстрируя гибкость подхода.

• Идея Dgsh оценивается как устаревшая по синтаксису, но перспективная для современных оболочек вроде nushell и elvish.
• Обсуждаются преимущества представления конвейеров данных в виде направленного ациклического графа (DAG) перед линейными пайплайнами.
• Сравнивается удобство Dgsh для создания конвейеров с написанием аналогичных задач на Python, Ruby или в чистом bash.
• Отмечается сложность работы с пайпами и процессами в Python по сравнению с shell-инструментами.
• Упоминаются альтернативные инструменты, такие как Murex, и фреймворки для оркестрации, например Apache Airflow.

Devbox — это инструмент для создания изолированных сред разработки на основе Docker. Каждый проект работает в собственном контейнере, что предотвращает конфликты зависимостей и сохраняет чистоту основной системы. Контейнеры автоматически перезапускаются и сохраняются между перезагрузками, а код остаётся на файловой системе хоста для удобного редактирования.

Инструмент предлагает простые команды CLI, встроенные проверки безопасности и шаблоны для Python, Node.js, Go и веб-разработки. Также поддерживаются расширенные функции Docker, такие как проброс портов, монтирование томов и настройка переменных окружения.

• Обсуждаются сходства и отличия Devbox от альтернатив: Devcontainers (от Microsoft), Toolbx, Distrobox и других, с акцентом на поддержку в разных IDE и сложность их реализации вне VSCode.
• Поднимается проблема конфликта имен с другими проектами, в первую очередь с Devbox от Jetify, что указывает на возможное отсутствие анализа существующих решений.
• Отмечаются вопросы о безопасности и изоляции, в частности, возможность использования Docker-in-Docker и её последствия.
• Участники делятся личным опытом использования Devbox и аналогичных инструментов, отмечая их удобство для создания воспроизводимых сред без потери производительности.
• Обсуждается, решает ли подход с контейнерами проблему "dependency hell" и насколько он оправдан для разных языков и типов разработки (веб, мобильная).

• Обсуждаются новые функции Claude Code: расширение для VS Code, команда /rewind для отмены изменений, переработанный интерфейс и управление контекстом.
• Пользователи сравнивают Claude Code с конкурентами (Cursor, Aider, Goose), отмечая его преимущества и недостатки, такие как интеграция с инструментами и эргономика.
• Поднимаются вопросы о конфиденциальности данных, потреблении ресурсов (ОЗУ) и проблемах с UX/UI в новом расширении VS Code.
• Обсуждаются технические аспекты: работа с CJK-вводом, управление памятью, поддержка MCP, а также использование тегов и магических команд в промптах.
• Высказываются предложения по улучшению: индикация функции в diff, отображение оставшегося контекста, отмена выполнения промпта и улучшение команды /resume.

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

Библиография предлагает инструменты для масштабируемой генерации данных, включая поддержку различных форматов инструкций, таких как Chain of Thought, и интеграцию с популярными платформами, включая Hugging Face. Она распространяется под лицензией Apache 2.0 и активно развивается с открытым исходным кодом.

• Представлен интерактивный инструмент для генерации синтетических данных с возможностью интерактивного редактирования и проверки на каждом шаге.
• Обсуждается техническая реализация: интеграция с существующими схемами БД, поддержка экспорта в txt/csv, переход от древовидных структур к графам (DAG).
• Упоминаются публично доступные синтетические датасеты (GSM8K, DevOps CoT) на Hugging Face для обучения моделей.
• Затронуты вопросы качества данных: низкий уровень дублирования и высокая диверсификация, проверяемая с помощью great-expectations.
• Проводятся параллели с другими методами (GLAN) и обсуждаются возможные заимствования кода между проектами.

Книга представляет собой структурированное введение в линейную алгебру, разбитое на пять глав, каждая из которых последовательно раскрывает ключевые концепции. Начинается с основ векторов и скаляров, включая операции над ними, скалярное произведение и проекции, затем переходит к матрицам и их свойствам, включая умножение, обратные матрицы и специальные типы вроде симметричных и диагональных. Третья глава посвящена системам линейных уравнений, методам исключения и LU-разложению, четвёртая — векторным пространствам, базисам и размерности, а пятая — линейным преобразованиям, их матричному представлению и свойствам вродя обратимости и проекций.

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

• Участники обсуждают учебные материалы по линейной алгебре, отмечая полезность книги "The Little Book of Linear Algebra" и её связи с практическими лабораторными работами.
• Возникает дискуссия о подходах к обучению: одни подчеркивают важность исполняемого кода для экспериментов, другие настаивают на необходимости изучения абстрактной теории с помощью математических учебников и ручных вычислений.
• Критикуются некоторые визуализации и определения в материалах (например, определение вектора), как вводящие в заблуждение или недостаточно строгие с математической точки зрения.
• Обсуждаются практические аспекты: применимость знаний для компьютерного зрения и машинного обучения, сравнение NumPy с другими инструментами (Octave, MATLAB) и важность интуитивного понимания.
• Автор книги отвечает на критику, поясняя свой подход и предлагая ссылки на дополнительные ресурсы (например, 3Blue1Brown) для лучшего визуального понимания.

Ollama представила новый API для веб-поиска, который позволяет моделям получать актуальную информацию из интернета, снижая риск галлюцинаций и повышая точность ответов. Бесплатный тариф доступен для индивидуального использования, а повышенные лимиты — через Ollama Cloud. API интегрирован с Python и JavaScript библиотеками, что упрощает создание инструментов для длительных исследовательских задач, включая работу с моделями вроде OpenAI gpt-oss.

Примеры кода демонстрируют использование через cURL, Python и JavaScript, возвращая структурированные результаты поиска с заголовками, URL и содержанием. Также показано, как построить поискового агента с помощью модели Qwen 3 от Alibaba, используя инструменты web_search и web_fetch для автоматизации запросов и обработки данных. Это расширяет возможности моделей, позволяя им активно взаимодействовать с веб-источниками в реальном времени.

• Вопросы о поисковом провайдере и лицензии на результаты поиска, включая возможность их хранения и перепубликации.
• Сомнения в бизнес-модели Ollama, её переходе от локального хостинга к облачным услугам и планам монетизации.
• Обсуждение технических альтернатив для локального поиска и индексации, а также интеграции с Ollama.
• Критика запуска функции веб-поиска без четкой документации по тарифам, лимитам и политике конфиденциальности.
• Предложения и опыт использования сторонних инструментов для поиска (SearXNG, Tavily, SERP API) и локальных решений.

Команда Wasmer анонсировала бета-поддержку Python в своей edge-платформе на базе WebAssembly. Это позволяет запускать популярные фреймворки вроде FastAPI, Django и Streamlit, а также библиотеки типа numpy и pandas — всё в песочнице с почти нативной производительностью. Ключевые улучшения включают динамическую линковку, поддержку сокетов, потоков и собственный индекс пакетов.

Производительность впечатляет: тесты показывают, что Python на Wasmer работает всего на 5% медленнее нативного, при этом обеспечивая изоляцию и портативность. Платформа уже обгоняет Cloudflare по поддержке мультитрединга и нативных модулей, а вскоре добавит полную поддержку PyTorch и других тяжёлых библиотек.

• Запуск Python в WebAssembly через Wasmer предлагает производительность, близкую к нативной, и обеспечивает надежную песочницу для выполнения кода.
• Обсуждаются практические применения: встраивание скриптов в приложения, серверные API (FastAPI, Django) и выполнение пользовательского кода в изоляции.
• Поднимаются вопросы о поддержке ключевых библиотек (numpy), асинхронности (asyncio) и межъязыкового взаимодействия (Python-JS).
• Отмечаются существующие альтернативы (Pyodide, контейнеры) и сложности с зависимостями, имеющими нативные расширения.
• WASM рассматривается как более простая и легковесная альтернатива виртуальным машинам и контейнерам для развертывания.

Python-разработчики всё чаще используют аннотации типов, чтобы повысить надёжность кода в условиях роста проектов от прототипов до промышленных систем. Гибкость динамической типизации, которая раньше ускоряла эксперименты в AI и data science, теперь становится риском для стабильности. Решение предложено в PEP 484 (2014) — постепенная статическая типизация, позволяющая добавлять аннотации без полного переписывания кода.

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

• Критика Python type hints как нарушающих дух языка, добавляющих излишнюю сложность и не дающих преимуществ в производительности.
• Поддержка type hints как ценной документации, улучшающей читаемость, рефакторинг и предотвращающей ошибки.
• Сравнение с другими статически типизированными языками (TypeScript, Rust), где система типов интегрирована лучше.
• Прагматичный подход: использование type hints выборочно, как подсказок, а не строгого требования.
• Влияние type hints на работу с ИИ-инструментами, улучшая автодополнение и понимание кода.

Python сохраняет лидерство благодаря своей универсальности в машинном обучении и веб-разработке, а JavaScript остаётся незаменимым для фронтенда. Rust продолжает расти из-за акцента на безопасность и производительность, особенно в системном программировании. Go набирает популярность в облачных сервисах и микросервисной архитектуре благодаря простоте и эффективной параллельной обработке.

Стоит отметить рост TypeScript как более строгой альтернативы JavaScript, а также стабильное присутствие Java в корпоративных приложениях. Интерес к Julia увеличивается в научных вычислениях, а Kotlin укрепляет позиции в мобильной разработке под Android. Практический вывод: выбор языка всё больше зависит от конкретной области, а не только от общей популярности.

• Сомнения в методологии рейтинга языков программирования IEEE из-за использования ненадёжных источников (поисковые запросы, устаревающий StackOverflow), что может искажать реальную картину.
• Удивление высокой позицией Java (2-е место), объясняемой её доминированием в enterprise-секторе (финансы, страхование, здравоохранение) и миграцией legacy-систем с COBOL.
• Обсуждение искусственного завышения позиции Python из-за его популярности у новичков, в академических статьях и как основного языка вывода для LLM.
• Предложение объединить рейтинги близких языков (JavaScript/TypeScript, Java/Kotlin, C/C++) для более точного отражения популярности экосистем.
• Размышления о влиянии AI-ассистентов на будущее языков: возможная стагнация из-за зависимости LLM от популярных языков или, наоборот, упрощение изучения нишевых.

Современный Fortran может быть предпочтительнее Python для обучения основам численной линейной алгебры из-за строгой типизации и явного управления памятью, что помогает студентам лучше понять внутреннюю работу алгоритмов. В Python студенты часто полагаются на готовые функции вроде np.linalg.solve, что скрывает детали реализации и приводит к ошибкам, связанным с динамической типизацией и неправильной индексацией массивов. Например, путаница между списками и массивами NumPy или неявное приведение типов могут затруднить отладку.

Fortran, напротив, требует чёткого объявления переменных и размеров массивов, что снижает риски ошибок и заставляет студентов продумывать структуру данных. Это особенно важно для таких задач, как метод Гаусса-Зейделя или метод наименьших квадратов, где понимание циклов и операций с матрицами критично. Хотя Python с его экосистемой удобен для сложных проектов, Fortran обеспечивает более прозрачный переход от математических формул к коду, укрепляя фундаментальные навыки.

• Обсуждается выбор языка для преподавания численных методов и линейной алгебры (Python, Fortran, Julia, C++ и др.), где Fortran хвалят за производительность и удобство для математики, а Python — за распространённость и простоту.
• Критикуется чрезмерно объектно-ориентированный подход в C++ для научных вычислений, а также сложности и "бородатость" некоторых языков (например, Fortran) для новичков.
• Поднимается вопрос о важности баланса между теоретической "чистотой" языка и его практической полезностью для будущей работы студентов.
• Отмечаются преимущества Julia и MATLAB/Octave для обучения благодаря близости их синтаксиса к математической нотации и удобным инструментам.
• Упоминаются проблемы с ошибками в Python (например, типизация и сообщения об ошибках), а также сложности отладки в сравнении с другими языками.

OpenDataloader PDF — это высокопроизводительный инструмент с открытым исходным кодом, предназначенный для безопасной обработки PDF-файлов в задачах искусственного интеллекта. Он обеспечивает извлечение текста и структурированных данных без риска утечки информации или выполнения вредоносного кода, что критично при работе с конфиденциальными документами. Проект оптимизирован для масштабируемости и интеграции в ML-пайплайны.

Ключевые особенности включают поддержку пакетной обработки, работу с加密рованными файлами и совместимость с популярными фреймворками. Это решение устраняет узкие места традиционных парсеров, предлагая предсказуемую производительность даже на больших объёмах данных. Для разработчиков важно, что инструмент снижает зависимость от проприетарных API и предоставляет прозрачный контроль над процессом обработки.

• Обсуждаются инструменты для извлечения структурированных данных из PDF (Camelot, Unstract, Cermine, docling), особенно для сложных документов вроде банковских выписок.
• Поднимается вопрос о необходимости нового AI-friendly формата вместо сложного для парсинга PDF.
• Рассматриваются ограничения и возможности современных LLM (большой контекст, needle-in-haystack тесты) для обработки больших документов.
• Упоминается поиск библиотек для извлечения таблиц из PDF, совместимых с C++.
• Отмечается, что некоторые инструменты используют кастомные парсеры, а другие полагаются на AI-модели для экстракции.

Локальная транскрипция аудио в текст на Python с помощью Whisper от OpenAI решает проблему приватности и затрат. Модель обрабатывает записи офлайн с точностью до 96%, поддерживает множество языков и шумовых условий. Ключевой шаг — установка FFmpeg для обработки аудио, без которой скрипт не заработает.

Доступно пять версий модели: от «tiny» (39 МБ, для тестов) до «large» (1.5 ГБ, максимальная точность). Для большинства задач подходит «base» — баланс скорости и качества. Код включает класс для транскрипции с выводом языка, времени обработки и сохранением результата в файл.

• Участники обсуждают локальные инструменты для преобразования речи в текст, такие как Whisper, SpeechShift и hns, с акцентом на автономность и интеграцию.
• Предлагаются методы улучшения качества транскрипции: предобработка аудио (конвертация в 16кГц WAV, фильтры), постобработка с помощью локальных LLM для очистки текста и снижения количества ошибок.
• Обсуждается добавление диаризации (распознавания говорящих) с помощью библиотек whisperx, pyannote и senko, а также её важность для повышения точности.
• Затрагиваются вопросы производительности, поддержки разных языков и использования аппаратного ускорения (например, Apple MLX) для ускорения обработки.
• Отмечается встроенная поддержка преобразования речи в текст в ffmpeg и упоминаются облачные альтернативы, такие как AssemblyAI, для сравнения точности.

Mojo теперь поддерживает программирование GPU на Apple Silicon, что делает разработку GPU-ускоренных алгоритмов и AI-моделей доступнее для владельцев современных Mac. Для работы требуется macOS 15, Xcode 16 и чипы M1–M4. Пока функциональность ограничена: не работают сложные примеры вроде матричного умножения, AI-модели, PyTorch-интеграция и некоторые аппаратные возможности. Планируется доработка поддержки atomic operations, bfloat16 и других функций.

Технически код компилируется в AIR bitcode через LLVM IR, затем в .metallib через Metal-cpp API, скрыто от разработчика. Существующий код для NVIDIA/AMD GPU должен работать, но для максимальной производительности потребуются оптимизации под архитектуру Apple. Документация и открытый вклад ожидаются позже, когда базовая инфраструктура будет стабилизирована.

• Обсуждение касается языка Mojo и его потенциала в области глубокого обучения и GPU-программирования, с акцентом на его совместимость с экосистемой Python и производительность.
• Участники спорят о нишевости написания кастомных CUDA/Triton ядер, отмечая, что это сложно и этим занимаются немногие, но Mojo может сделать этот процесс более доступным.
• Высказываются как скептические мнения о будущем Mojo (называя его "проектом тщеславия"), так и оптимистичные, видящие в нём важный прорыв и альтернативу существующим инструментам.
• Поднимаются вопросы о бизнес-модели Mojo (лицензирование) и её потенциальном влиянии на открытость экосистемы, что может отпугнуть часть разработчиков.
• Отмечается, что синтаксис Mojo, основанный на Python, является его сильной стороной для привлечения аудитории data scientists, но сама языковая модель и runtime отличаются.

Timesketch — это инструмент от Google для совместного анализа временных линий в цифровой криминалистике. Он позволяет исследователям импортировать, анализировать и совместно работать с данными, собранными в ходе расследований инцидентов безопасности. Система поддерживает интеграцию с популярными инструментами, такими как Plaso, и предоставляет веб-интерфейс для визуализации событий, поиска по временным меткам и аннотирования находок.

Ключевые возможности включают масштабируемость для больших объёмов данных, поддержку множества пользователей с разными ролями и расширяемость через API и плагины. Это делает Timesketch полезным как для внутренних расследований в компаниях, так и для академических или судебных исследований. Практический вывод: инструмент снижает порог входа в цифровую криминалистику, упрощая анализ сложных данных.

• Обсуждается статус проекта Timesketch: код принадлежит Google, но не является официальным продуктом, а скорее инициативой сотрудников, выпущенной через внутренний процесс.
• Уточняется функционал инструмента: это средство для анализа временных линий (логов) с бэкендом на Python 3 и фронтендом на Vue.js, предназначенное для совместной работы при расследовании инцидентов.
• Отмечается возможное происхождение проекта от внутренних команд реагирования на инциденты Google.
• Подчеркивается, что размещение в организации Google на GitHub не означает официальной поддержки компании, а лишь то, что код был выпущен сотрудником.
• Обсуждается практическая польза инструмента для создания единой временной шкалы событий из разных источников для расследования киберинцидентов.

WeAct Display FS — это компактный USB-дисплей за $2 с диагональю 0,96 дюйма и разрешением 160×80 пикселей. Он подключается к компьютеру или одноплатнику через обратимый USB Type-A порт, что позволяет гибко ориентировать экран. Устройство отображает системную информацию, погоду или пользовательские изображения через специальное ПО.

Программное обеспечение включает WeAct Studio System Monitor, форк проекта Turing Smart Screen на Python, который теоретически работает на Windows, macOS, Linux и Raspberry Pi OS. Для удобства использования в комплекте идут прокладки, предотвращающие короткое замыкание при перевороте USB-разъёма.

• Выражен интерес к USB-дисплеям с e-Ink, открытым интерфейсом и энергонезависимостью изображения, но отмечена высокая цена и дефицит подходящих моделей.
• Подняты серьёзные опасения по безопасности из-за риска подмены устройства клавиатурой для ввода вредоносных команд.
• Обсуждаются альтернативы: перепрошивка существующих устройств (ESP32, LilyGo), использование старых ридеров или более крупных дисплеев (M5Paper, reTerminal).
• Отмечен феномен покупки гаджетов "для проектов", которые затем не реализуются и пылятся.
• Высказано удивление распространением миниатюрных экранов в неожиданных местах как символа "будущего".

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

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

Корень проблемы не в выборе языка (YAML vs. альтернативы), а в том, что мы недооцениваем конфигурационные файлы как пользовательские интерфейсы. Они должны обеспечивать отличный UX: предотвращать ошибки, вести пользователя к успеху и работать как «велосипед для ума».

Пример реализации такого подхода — проект KSON, который позиционируется как более эффективная альтернатива YAML/JSON/TOML. KSON является верифицированным надмножеством JSON, поддерживает JSON Schema и предлагает инструменты для улучшения работы с конфигурациями.

• Критика KSON за отсутствие чувствительности к пробелам, что может приводить к неочевидным ошибкам парсинга, как в примере с вложенным списком портов.
• Обеспокоенность рисками безопасности из-за единственной реализации на Kotlin и сложностей сборки для других языков, таких как Python и Rust.
• Предложение использовать полноценные языки программирования (например, Python) для конфигурации вместо специализированных форматов, чтобы дать пользователям больше инструментов.
• Аргумент в пользу того, что конфигурационные форматы должны быть выразительными, но ограниченными (как Cue, Starlark или Dhall), а не просто данными, как JSON или YAML.
• Подчёркивание различия между форматами для людей (конфигурация) и для компьютеров (данные), и критика попыток совместить их в одном формате.
• Замечание, что сложная конфигурация часто указывает на проблемы в дизайне ПО, и что лучше предоставить пользовательский интерфейс вместо сложных файлов.
• Упоминание альтернатив, таких как TOML, HJSON, HOCON, KDL и Jsonnet, с различными подходами к простоте, выразительности и проверке типов.

В Unicode существует больше символов, обозначающих «латинскую заглавную букву A», чем букв в английском алфавите. Это наблюдение вдохновило на создание «шифра крика» — замены каждой буквы на один из вариантов A с диакритическими знаками. Например, фраза «SCREAM CIPHER» превращается в «ǠĂȦẶAẦ ĂǍÄẴẶȦ», что выглядит как набор кричащих символов.

Функции SCREAM и unscream реализуют прямое и обратное преобразование, сохраняя при этом регистр и игнорируя не-буквенные символы. Такой подход демонстрирует игривое использование Unicode для создания визуально эффектного, но семантически тривиального шифрования.

• Представлена кодировка zalgo256 с использованием комбинирующих символов Unicode для создания "кричащего" шифра, аналогичного моноалфавитной замене.
• Обсуждаются юмористические и практические аспекты шифра, включая сравнение с ROT13, отсылки к XKCD и потенциальное применение для обхода ограничений длины строк.
• Участники делятся своими реализациями на разных языках (Python, JS, Racket) и идеями по скрытию данных с помощью невидимых символов или эмодзи.
• Поднимаются вопросы безопасности, указывается на отсутствие криптостойкости и обсуждаются технические детали работы с графемными кластерами в Unicode.
• Шифр вызвал оживлённую реакцию, включая шутки о "песчаных людях" из Star Wars и создание чат-ботов для кодирования.

Навигационное меню GitHub с разделами:

- Платформа: Copilot, Spark, Models, Advanced Security, Actions, Codespaces, Issues, Code Review, Discussions, Code Search
- Решения: для предприятий, малых команд, стартапов, некоммерческих организаций
- Ресурсы: статьи по AI, DevOps, безопасности, разработке ПО
- Open Source: спонсоры, проекты, репозитории
- Enterprise: платформа, дополнения
- Цены

Поиск кода, репозиториев, пользователей, issues и pull requests. Возможность сохранения поисковых запросов.

• NVIDIA Tilus представляет собой низкоуровневый инструмент для контроля над регистрами, возможно, как ответ на Triton, который поддерживает AMD и другие ускорители, угрожая экосистеме CUDA.
• Название Gluon уже используется несколькими проектами, включая язык для ML от Amazon/Microsoft, UI-тулкит для Java и встраиваемый язык для Rust, что создает путаницу.
• Gluon от NVIDIA рассматривается как сходный с их же CUTE DSL, что указывает на convergence к оптимальному дизайну Python-based DSL для программирования ядер.
• Мнения разделились: одних смущает, что «язык» остается кодом на Python, требующим трассировки, другие считают такой подход на основе AST-walker эффективным.
• Появление Gluon связано со сложностями Triton в достижении высокой эффективности на новых архитектурах NVIDIA, таких как Blackwell.
• NVIDIA разрабатывает множество DSL, что свидетельствует о их беспокойстве из-за открытых и портируемых альтернатив CUDA.
• На экосистему CUDA оказывают давление крупные компании, разрабатывающие собственные чипы для AI, чтобы избежать зависимости от NVIDIA.

• LLMs демонстрируют сильные способности в математике и науке, но проваливаются на простых визуальных и пространственных головоломках, таких как Sokoban или ARC-AGI.
• Основная проблема LLM — отсутствие подлинного понимания и рассуждений; они работают через распознавание паттернов, а не через логическое мышление.
• LLMs особенно слабы в пространственных рассуждениях, так как обучались в основном на текстовых данных, а не на визуальной информации.
• Некоторые участники связывают неудачи LLM с форматом представления данных (например, визуальные головоломки в текстовом виде) и отсутствием мощных препроцессинговых блоков для изображений.
• Предлагаются методы улучшения, включая эволюционные алгоритмы, поиск с подкреплением (RL) и создание каркасов (scaffolding) для решения задач.
• Есть скептицизм относительно того, что улучшение производительности на узких тестах (как ARC-AGI) свидетельствует о прогрессе к AGI.
• Обсуждается, является ли решение головоломок LLM результатом доступа к публичным обсуждениям этих задач, а не новыми возможностями рассуждений.

• Обсуждаются строгие правила CRAN для R-пакетов, требующие обратной совместимости и тестирования всех зависимых пакетов при обновлении, что сравнивают с монорепозиторием.
• Поднимаются проблемы других экосистем (Python, npm), где распространены ломающие изменения и конфликты зависимостей, и отмечается стабильность R.
• Участники спорят о практичности подхода CRAN: одни видят в нём бремя для разработчиков, другие — выгоду для научной воспроизводимости и пользователей.
• Предлагаются альтернативы и обходные пути, такие как полное форкирование, версионирование API или контейнеризация.
• Отмечается уникальная философия R-сообщества, ориентированная на статистиков, а не на разработчиков, что объясняет такие жёсткие требования.

Делай вклад в цифровые общественные блага

Помоги проектам, которые борются с климатом, голодом и прочими глобальными задачами. Ниже — готовые к первому PR репозитории.

Проект	Язык	Направление
mautic	PHP	маркетинг-автоматизация
credebl	TypeScript	децентрализованная идентичность
avni-webapp	JavaScript	медицинские данные
the-turing-way	TeX	воспроизводимая наука
X-Road	Java	обмен данными между госорганами
OpenTermsArchive	JavaScript	прозрачность сервисов
OpenFn Lightning	Elixir	автоматизация workflow
android-fhir	Kotlin	мобильная медицина
casa	Ruby	волонтёрство для детей
ODK Collect	Kotlin	сбор данных в поле
cht-core	JavaScript	цифровое здравоохранение
policyengine-app	Jupyter	расчёт последствий политик
querido-diario	Python	открытые госгазеты
ODK Central	JavaScript	сервер для форм
decidim	Ruby	участие граждан

Фильтр по языку и Целям устойчивого развития (SDG) на сайте.

• Участники приветствуют инициативу списка проектов с «good first issue», но сомневаются в кураторстве: много проектов без активных задач, не все связаны с социальным влиянием.
• Предложено скрывать репозитории с 0 issues и добавлять метрики активности (коммиты, разработчики, возраст), как в Re-Decentralise.
• Новички спрашивают, считать ли правку опечаток «настоящим» вкладом; большинство советует упоминать, но честно указывать уровень участия.

Real-Time-Voice-Cloning
Клонирование голоса за 5 секунд и синтез любой речи онлайн.

• Архитектура: encoder → synthesizer → vocoder.
• Датасет: 1–2 минуты чистой речи на диктофон.
• GPU: ≥6 ГБ VRAM, CPU тоже работает.
• Установка: клонируй репо, поставь зависимости, скачай веса.
• GUI: запусти demo_toolbox.py, выбери wav, вводь текст.
• API: python demo_cli.py <wav> "<текст>".

• Модель VibeVoice от Microsoft, умеющая клонировать голоса, удалили с GitHub, несмотря на MIT-лицензию.
• Причина: её стали использовать «не по назначению».
• Пользователи отмечают: технология уже «вышла из бутылки» с 2021 года и распространяется opensource.
• Обсуждаются простые способы самостоятельно воспроизвести «голосовые эмбеддинги» без официальной модели.
• Вопрос: способны ли системы Voice ID защититься от подделки ИИ? Ответов пока нет.

Паперовое 3D-моделирование
Сокращённый перевод

---

Плюсы хобби:

• Дёшево: бумага, ножницы, клей.
• Техника + творчество: проектируешь как инженер.
• Без ограничений: лишь бы хватило терпения.

---

Мой пример: модель самолёта SR-71 Blackbird.

---

Самоограничения

• Только бумага, без принтованных текстур.
• Однотонные детали.
• Простые многогранники: без дыр, скруглений, «лишних» соприкосновений.

Зачем? Проще собирать, прочнее держится, легко повторить.

---

Цели

1. Сборка без мучений – главное.
2. Похоже на оригинал.
3. Минимум бумаги и времени.

---

Цикл проектирования

1. 3D-сетка – строим полиэдр.
2. Развёртка – раскладываем на лист.
3. Сборка – проверяем, улучшаем.

• Участники вспомнили детство: кто-то складывал оригами SR-71, кто-то собирал шлемы Halo из бумаги.
• Популярность бумажных моделей в Восточной Европе (Польша, Чехия, Словакия, СССР) отмечена как региональная особенность.
• Обсуждали инструменты: Pepakura, Blender с экспортом в развёртки, PythonSCAD, плоттеры Cricut.
• Автор статьи сам ограничил себя: только плоские полигоны, без цилиндров и текстур, чтобы упростить сборку.
• Некоторые предлагали автоматизировать подбор «развёртываемых» поверхностей (developable surfaces) и использовать станки для резки.

PythonBPF – пишем eBPF-программы на чистом Python
(в 2 раза короче)

---

Что это
Библиотека pip install pythonbpf компилирует Python-код в объектные .o-файлы и загружает их в ядро как обычные eBPF-программы. Репо: GitHub.

---

Было
Встраивали C в многострочные строки, теряя линтеры и подсветку:

from bcc import BPF
prog = """
int hello(void *ctx) {
    bpf_trace_printk("Hello\\n");
    return 0;
}
"""
b = BPF(text=prog)
b.attach_kprobe(event="sys_clone", fn_name="hello")

---

Стало
Тот же функционал — на Python:

from pythonbpf import bpf, section, compile
from pythonbpf.maps import HashMap
from pythonbpf.helpers import ktime
from ctypes import *

@bpf
def last() -> HashMap:          # глобальная BPF-мапа
    return HashMap(c_uint64, c_uint64, 1)

@bpf
@section("tracepoint/syscalls/sys_enter_execve")
def hello(_: c_void_p) -> c_int32:
    print("entered")
    return 0

@bpf
@section("tracepoint/syscalls/sys_exit_execve")
def bye(_: c_void_p) -> c_int64:
    print("exited")
    last().update(0, ktime())
    return 0

@bpf
def LICENSE() -> str:           # лицензия ядра
    return "GPL"

compile()                       # → .o и загрузка

---

Как работает

1. ast → дерево
2. llvmlite → LLVM IR
3. llc → BPF-объект
4. libbpf → загрузка в ядро

• Участники обсуждают инструмент для компиляции Python в eBPF байт-код, который был создан как проект на хакатоне и пока считается «игрушечным».
• Подчеркивается, что использование LLVM для трансляции в eBPF — более перспективный подход, чем прямое преобразование Python-байткода.
• Несколько пользователей отмечают отсутствие четких объяснений, что такое eBPF, и предлагают добавить больше документации и примеров.
• Критикуется идея использования LLM (больших языковых моделей) для генерации eBPF-кода из-за строгой проверки и специфики eBPF.
• Упоминаются существующие аналогичные проекты для других языков (Java, Node.js) и инструменты из мира BCC.
• Автор проекта признает, что код находится на ранней стадии и требует значительной доработки.

fartscroll-lid — забавное приложение для macOS, которое воспроизводит пукающие звуки при открытии и закрытии крышки MacBook.

• Проект — пародийный форк датчика угла крышки MacBook, издающий пукающий звук при открытии/закрытии.
• Пользователи сравнивают его с легендарным fartscroll.js и вспоминают старые тролл-экстензии вроде MacSniff или iFart.
• Популярные идеи: тайно установить ноутбук шефу, сделать «жующие» звуки или играть «Farty Bird» хлопая крышкой.
• Просят видео-демо, жалуются на xattr-инструкции и обсуждают Python-версии без Xcode.
• Тред быстро превратился в весёлую ветеранскую встречу троллей 90-х–00-х, вспоминая AIM, ICQ и THX.

Асинхронное программирование 2.0
Автор: Ankur Goyal, 19 авг 2025

Я перестал писать код руками. Описываю задачу — агент пишет TypeScript/Rust/Python, тесты и коммитит. Я возвращаюсь только на ревью. Это не «вайб-кодинг», а новый цикл: чётко определяю → делегирую → проверяю.

Как работает

1. ТЗ как код: «снизить задержку поиска с 800 до 200 мс, убрав аллокацию в цикле».
2. Автопроверка: юнит- и интегра-тесты, типы, бенчи, линтеры — всё в CI.
3. Жёсткое ревью: агенты ошибаются, поэтому читаю PR дольше, чем писал раньше.

Плюсы

• Параллельно веду 4–5 задач: одну в фокусе, остальные в фоне.
• Система всё равно моя: архитектура и решения остаются моими.

Braintrust
Собственный агент Loop принимает описание eval-задачи и в фоне улучшает промпты, датасеты и скоры.

• «Async programming» в статье — это не про async/await, а про делегацию коду ИИ-агентам; название вызывает путаницу и споры.
• Ключевой шаг — чётко описать задачу; критики считают это самым трудным и редким навыком.
• Опасения: атрофия собственных навыков, взрыв технического долга, потеря удовольствия от программирования.
• Сторонники отмечают высокую скорость итераций и полезность ИИ для «скучного» кода (тесты, скрипты).
• Опыт офшоринга показывает: без точных спеков результат — задержки и недопонимание; ИИ ускоряет получение «среднего» кода, но не решает проблему спецификаций.

Как я вживил LLM в Animal Crossing без единой правки кода

Проблема
GameCube-версия Animal Crossing 2001 года повторяет те же фразы 23 года. Консоль оффлайн, 24 МБ ОЗУ, нет TCP/IP.

Решение

1. Декомпиляция: сообщество выложило исходники на C, нашёл mMsg_ChangeMsgData.
2. «Почтовый ящик» в ОЗУ: выделил кусок RAM (0x81298360) для обмена строками.
3. Сканер памяти: замораживал эмулятор, искал адреса активного текста и имени собеседника.
4. Мост: Python-скрипт читает имя персонажа, шлёт запрос к LLM, пишет ответ прямо в буфер диалога.
5. Никаких патчей картриджа: всё через Dolphin + чтение/запись процесса.

Итог
В villagers теперь живой чат, а консоль по-прежнему думает, что 2001 год.

• Мод перехватывает диалог Animal Crossing на GameCube через shared-memory «почтовый ящик» и подменяет строки ответами LLM.
• Игра приостанавливается на секунды, пока внешний Python-скрипт запрашивает ответ у модели и кладёт его обратно в память.
• Первые сгенерированные реплики villagers’ов — «свергнуть Тома Нука», что вызвало веселье и обсуждение капиталистической сатиры.
• Участники видят в моде будущее игр: бесконечные, контекстуальные реплики вместо заезженных фраз, но сомневаются в производительности и сюжетной последовательности.
• Проект напомнил о старых попытках встроить ИИ в NPC (Quake 3, Skyrim, Modbox) и вызвал желание повторить для Switch-версий, хотя DRM усложняет декомпиляцию.

• Атакующий случайно раскрыл свою инфраструктуру: оставил открытым Git-репозиторий с исходниками вредоноса, скриптами и конфигами.
• Внутри: Python-стиллер, нацеленный на браузеры, крипто-кошельки, 2FA; обфускация через pyarmor; авто-апдейт через Telegram.
• Следы ведут в русскоязычное комьюнити: комментарии, ники, форумы.
• Уязвимость в C2 позволила аналитикам Huntress скачать 30 ГБ логов жертв: пароли, cookies, крипто-сид-фразы.
• Ошибка раскрыла 1 800+ уникальных пользователей за 3 месяца; сам стиллер активен с 2023.
• Huntress заблокировал домены и передала IOC партнёрам; инцидент подчёркивает ценность мониторинга «мелких» endpoint-угроз.

• Huntress — это EDR-решение для компаний, которое ставит агент на каждый корпоративный ПК и передаёт в SOC-отдел логи браузера, процессов, hostname и файлы.
• Пользователи возмущены: «устанавливать продукт безопасности = дать поставщику полный доступ к истории и данным».
• Сам пост — история «случайно пойманного» злоумышленника, который сам установил триальный агент Huntress на свою «хакерскую» машину; компания узнала его по старому hostname и опубликовала разбор действий.
• Критики считают это саморекламой и примером «шпионажа за клиентами»; вендор отвечает: «анализируем только подозрительное, логи доступны заказчику, нужно для расследований».
• Комментаторы напоминают: в больших компаниях подобные EDR-инструменты (CrowdStrike, SentinelOne и др.) стоят на каждом ПК де-факто, просто обычно об этом не пишут посты.

## DOOMQL: шутер в чистом SQL

**Идея**  
- Всё состояние — в таблицах CedarDB  
- Картинка = стек VIEW с трассировкой лучей  
- Цикл — bash-скрипт, 30 FPS: `psql < game.sql`  
- Клиент — 150 строк Python: читает клавиши, SELECT’ит кадр  

**Схема (сокращённо)**  
```sql
config( move, turn, ammo_max … );  
map(x,y,tile);  
players(id,hp,ammo…);  
inputs(player_id,action);  
mobs(id,x,y,angle,type);  
sprites(id,texture,offset);

Рендер

1. rays — лучи от игрока, столкновения со стенами
2. walls — высота линии = 1 / distance
3. sprites — проекция по x, z-order
4. frame — UNION walls+sprites, строка = пиксель
5. hud — здоровье, ammo, миникарта в ASCII

Мультиплеер

-- добавить игрока  
INSERT INTO players VALUES(:id);  
-- чужие движения  
SELECT * FROM players WHERE id != :me;

Производительность

• 640×480 ≈ 30 кадр/с на ноутбуке
• CedarDB распараллеливает лучи между ядрами

Читерство

UPDATE players SET hp=100, ammo=99 WHERE id=my_id;

Вывод
База = готовый игровой сервер: транзакции дают согласованность, а SQL — ещё и консоль читов.

• Кто-то запустил мультиплеерный «Дум» на чистом SQL (CedarDB), и это вызвало волну «Krieger, ты с ума сошёл!»
• Половина комментаторов спорит: это всё-таки Doom или всё же Wolfenstein 3D без текстур
• Автор признаётся, что вдохновился DuckDB-DOOM и просто называет любой 2.5D-шутер «думоподобным»
• Кто-то видит в проекте хитрую рекламу CedarDB (PostgreSQL-совместимый HTAP), другие – новую игру в «а тьюринг-полно ли это?»
• Участники сравнивают с ASCII-Doom, pg_doom и мечтают о полноценной MMO, целиком живущей в базе данных

• Claude теперь генерирует Excel, Word, PowerPoint и PDF прямо в чате.
• Доступно для Max/Team/Enterprise, Pro — позже.

Как использовать:

1. Включить «Upgraded file creation» в Settings > Features > Experimental.
2. Загрузить данные или описать задачу.
3. Скачать готовый файл или сохранить в Google Drive.

Возможности:

• Очистка данных, анализ, графики, пояснения.
• Финмодели, трекеры, бюджеты с формулами.
• PDF → слайды, заметки → документ, счета → таблицы.

Claude пишет код в изолированной среде, превращая идеи в файлы за минуты. Начните с простых отчётов, затем переходите к сложным моделям.

• Клод получил «Code Interpreter»-режим: в песочнице устанавливает pip-пакеты и запускает Python, чтобы создавать/редактировать локальные файлы (XLSX, PDF, диаграммы и т.д.).
• У пользователей растёт недовольство надёжностью: артефакты «залипают», правки не применяются, модель часто «тупит» и тормозит даже у подписчиков Pro/Max.
• Часть комментаторов считает фичу полезным дополнением к аналитике, другие — пиаром «старого» функционала, а кто-то опасается всплеска малвари и фишинга.
• Конкуренты (ChatGPT, Copilot) уже умеют запускать код и отдавать zip-архивы, поэтому новинка воспринимается как догоняющий, а не прорывной шаг.
• Основной запрос сообщества: «Сначала почините стабильность и качество модели, потом добавляйте новые фичи».

Содержимое PDF-файла представляет собой бинарные данные, которые нельзя напрямую интерпретировать как текст. В представленном фрагменте — это служебные структуры PDF (объекты, потоки, метаданные), а не читаемый текст документа.
Перевод и сокращение невозможны, поскольку отсутствует осмысленный текстовый контент.

• Брукс по-прежнему прав: основная трудность — «существенная сложность» предмета, а не инструменты.
• За 40 лет не появилось ни одного «серебряного пули», дающего 10× прирост продуктивности.
• Экосистемы (Python, AWS и др.) снизили accidental complexity, но добавили новую через зависимости и «слоёный пирог».
• LLM и ИИ ускоряют рутину, но не решают существенную сложность и не умеют формулировать требования.
• Культура SWE изменилась: скорость вытеснила ответственность, код пишут «на скорую руку» и быстро забывают.

Microdot: крошечный веб-фреймворк для всего

Мигель Гринберг, автор Flask Mega-Tutorial, представил Microdot — мини-фреймворк, работающий и на CPython, и на MicroPython: от IoT до облаков.

Зачем?
Зимой 2018-го в Ирландии Мигель столкнулся с «умным» отоплением, которое погрешало на ±3 °C. Он отключил термостаты, поставил на каждый этаж плату с MicroPython и датчиком (±0,5 °C) и сам включал/выключал нагрев.
Чтобы с дивана видеть температуру и статус, ему нужен был веб-сервер, но Flask и Bottle на MicroPython не лезли. Поэтому он написал Microdot — «Flask в миниатюре».

Фишки

• одна папка, ~1500 строк, нулевые зависимости
• маршруты, шаблоны, cookies, WebSocket, SSE, CORS, SSL, Basic/Digest-аутентификация, тест-клиент
• копирует API Flask: @app.route, request.args, jsonify, abort, before_request
• работает на ESP32, Raspberry Pi Pico, обычных серверах
• ставится pip install microdot (CPython) или mip install microdot (MicroPython)
• опциональные плагины: microdot-session, microdot-cors, microdot-websocket, microdot-jinja, microdot-asyncio

Код

from microdot import Microdot
app = Microdot()

@app.route('/')
async def index(req):
    return {'temp': 22.5, 'heating': False}

app.run(port=80, debug=True)

Размер
ESP32: 70 КБ свободной ОЗУ остаётся после загрузки MicroPython + Microdot + приложение.
CPython: ~1 МБ venv.

Кому

• хобби-IoT: датчики, реле, роботы
• встраиваемые системы: промышленные контроллеры, автономные датчики
• прототипы: быстро поднять REST, потом перейти на Flask/FastAPI
• обучение: Flask-разработчики учатся за пять минут

Где
GitHub: github.com/miguelgrinberg/microdot
Документация: microdot.readthedocs.io
PyPI: pip install microdot

• Microdot — это 765-строковый Python-фреймворк, который работает и на CPython, и на MicroPython; предназначен для веб-серверов на IoT-устройствах (ESP32 и др.).
• Автор @miguelgrinberg подтвердил, что расширения (шаблоны, сессии) опциональны и почти не требуют зависимостей; версия 2 внесла ломающие изменения.
• Комментаторы спорят о слове «impossibly small»: кто-то считает 765 строк нормальным минимумом, кто-то — перебором; сравнивают с Bottle, Rails 0.x и FW/1.
• Пользователи делятся опытом: SSE + htmx для живых GPIO-индикаторов, бенчмарки RPS, проекты термостатов и садовых сенсоров.
• Упоминаются альтернативы (TurboLua, BirSaat) и вопрос: «почему бы не написать это на C?»

• Крис Латтнер (LLVM, Swift) делает новый язык Mojo, чтобы ML-код был быстрым и удобным.
• Проблема: GPU-ядра пишутся на CUDA/OpenCL вручную, медленно и зависят от одного вендора.
• Решение: язык с метапрограммированием и типами, который «знает» об аппаратуре и генерирует оптимальный код под любую платформу.
• Цель: один код → любой GPU/CPU, открытая экосистема, no lock-in.

• Mojo обещает «Python++, но быстрый», но до сих пор нет полноценных классов, а «полный суперсет» превратился в мягкое «всё ещё не Python».
• Лицензия проприетарная — для многих это стоп-фактор: «сделайте GPL или идите лесом».
• Экосистема Python неподвластна: все уже завязаны на PyTorch/CUDA, а Mojo пока не даёт причин мигрировать.
• Julia, Elixir/Nx, CuPy, Triton, Numba — всё уже умеют «быстро + GPU», без нового языка.
• Итог: Mojo выглядит технически интересным, но «ещё один закрытый язык» в 2025 году воспринимается как ненужный риск.

Классические 8×8 ч/б узоры Mac
Сделал сайт с 38 оригинальными узорами 1984 года: paulsmith.github.io/classic-mac-patterns.

Использовал Mini vMac + System 6, вытащил ресурс PAT# из файла System, распаковал .sit, прогнал DeRez, получил hex-данные.
Python-скрипт превратил их в .pbm, потом ImageMagick (-filter point) — в PNG любого размера.

Получились чистые, пиксель-в-пиксель копии узоров из Control Panel и MacPaint.

• Участники делятся находками и собственными реконструкциями 8×8-узоров рабочего стола Mac/Windows/X11.
• Обсуждают, как в 64 битах уместить выразительные текстуры и вытаскивать PAT-ресурсы через ResEdit, эмуляторы или hex-дампы.
• Показывают интерактивные редакторы: Mac Control Panel, Win 3.1, X11 xsetroot, вариант для System 7.
• Отмечают кроссплатформенность «wide weave» и других узоров, встречающихся от C64 GEOS до Atari ST.
• Спорят о цветных паттернах Mac OS 7, e-ink и о том, как поставить 1-битовый дизайн обоями на iPad.
• Вспоминают ResEdit, hidden-опции Option-ключа и находят в теме «настоящую археологию» 80–90-х.

Репозиторий показывает, как в Racket писать анонимные рекурсивные функции без letrec и имен.
Ключевая идея — Y-комбинатор: лямбда получает себя как аргумент и вызывает его для следующего шага.

(define Y
  (λ (f)
    ((λ (x) (x x))
     (λ (x) (f (λ (a) ((x x) a)))))))

((Y (λ (fact)
      (λ (n)
        (if (zero? n) 1 (* n (fact (sub1 n)))))))
 5) ; 120

Такой приём работает для любой рекурсии: факториал, fib, обход списков и т.д.

• Обсуждение началось с примера анонимной рекурсии на Racket; оказалось, что код совместим с любым R6RS-Scheme, включая проект scheme-rs.
• Участники сравнили подходы: в Clojure нужен явный recur, в Racket хвостовые вызовы оптимизируются автоматически.
• Кто-то спросил, стоит ли брать Racket для повторного изучения ФП; советуют почитать «zen of Racket» и быть готовым к узкой, но мощной экосистеме.
• Появились порты идеи на Python и Go (через Y-комбинатор), но часть людей предпочла бы обычный цикл для отладки.
• Сообщество предупреждает: в нишевых языках придётся уметь докручивать библиотеки «с нуля» и держать редких специалистов.

Краткий обзор компилятора C на 500 строк Python

Автор бросил себе вызов — написать компилятор C за 500 строк Python. Получилось трудно, но рабочий результат.

Архитектура

• Однопроходный: парсинг и генерация кода идут одновременно. AST не строится, экономим строки.
• Цель — WebAssembly: выбор странный (goto нет, стек-VM), но интересный. Пришлось реализовать собственный стек в памяти, т.к. стек WASM нельзя адресовать.

Что вырезали

• switch, do/while, goto, break/continue, enum, union, typedef, const/volatile, static, inline, sizeof, float, double, long, long long, void *, массивы, указатели на функции, структуры в структурах, varargs, макросы, #include, стандартную библиотеку.

Лексер

Регулярки разбивают исходник на токены: ключевые слова, идентификаторы, числа, операторы, строки и символы.

Парсер

Рекурсивный спуск. Пример префиксного ~:

elif lexer.try_next("~"):
    meta = load_result(prefix())
    emit("i32.const 0xffffffff")
    emit("i32.xor")
    mask_to_sizeof(meta.type)
    return meta

Семантика типов

Поддержаны int, char, short, int *, char *, struct. Все сводится к 32-битным целым. Структуры выравниваются по 4 байта.

Управление памятью

• Локальные переменные кладутся в стек.
• Глобальные — в секцию data.
• malloc/free нет, но можно вызвать внешнюю malloc из JS.

Циклы for

Из-за отсутствия goto пришлось генерировать вложенные блоки WebAssembly и использовать br_if для break/continue.

Функции

• Поддерживаются int аргументы и возвращаемые значения.
• Вызовы через call.
• Рекурсия работает.

Сборка и запуск

python compiler.py input.c > output.wat
wat2wasm output.wat -o output.wasm
node run.js output.wasm

Итог

500 строк Python компилируют подмножество C в WASM. Код читаемый, эксперимент удался.

• Пользователь удивился, что даже GCC и Clang не реализуют весь стандарт C.
• Обсуждали, что однопроходный компилятор проще, но без оптимизаций, и что C изначально проектировался именно под такой подход.
• Упомянули книгу «Writing a C Compiler» Норы Сандлер как хорошее руководство.
• Кто-то сравнил компиляторы с лингвистикой, другие отметили, что C несёт 50-летний технический долг.
• Шутили о написании Python-компилятора на C за 500 строк и о том, что без импортов это будет «обёртка», а не компилятор.

VibeVoice — открытая TTS-модель для создания экспрессивных многоспикерных диалогов (подкасты, интервью).

• Токенизаторы акустический и семантический работают на рекордно низкой частоте 7,5 Гц, сохраняя качество и ускоряя длинные последовательности.
• Архитектура: LLM понимает контекст и диалог, диффузионный «голова» добавляет детали.
• Пределы: до 90 минут, до 4 голосов, поддержка фоновой музыки, спонтанных эмоций и пения.
• Кросс-язычность: свободный перевод с/на китайский и английский.

• Качество VibeVoice высокое, но мужские голоса часто звучат роботизированно и попадают в «зловещую долину».
• Женские образцы заметно реалистичнее; демо-сайт почти всегда начинает с них.
• Лучшие альтернативы: HiggsAudio (быстрее и чище), Kokoro (для слабых GPU) и Chatterbox.
• Модель хорошо клонирует голос и эмоции, поддерживает английский, китайский и индийские акценты, но не SSML и редкие языки.
• Репозиторий временно закрыт, лицензия MIT, но данных обучения не раскрыто.

Ключевые выводы исследования Cisco по обнаружению открытых серверов Ollama

• Цель: выявить уязвимые LLM-серверы, запущенные через фреймворк Ollama.
• Метод: Python-скрипт, сканирующий Shodan на признаки открытых API /api/tags, /api/ps, /api/chat.
• Результаты: найдено >1 100 публичных инстансов; ~20 % допускают анонимный чат и загрузку моделей.
• Риски: утечка данных, DoS, финансовые потери (GPU-трафик), инъекция вредоносных моделей.
• Рекомендации:
  • включить авторизацию и TLS;
  • фильтровать IP-адреса;
  • отключить --network host;
  • использовать reverse-proxy (nginx, traefik) и WAF;
  • регулярно сканировать инфраструктуру.

• Cisco сообщила об открытых в интернете >1 100 серверов Ollama без аутентификации.
• Ollama по умолчанию не требует пароля и не планирует встроенной защиты API.
• Пользователи решают проблему через firewall, nginx/caddy с токеном или VPN.
• Сообщество спорит: виноваты ли разработчики, админы или «вайб-кодеры».
• Многие считают риск низким, пока LLM не подключены к инструментам и чувствительным данным.

• Async в Python уже 10 лет, но до сих пор не стал мейнстримом.
• Причины:
  • ошибки «забыл await», трудно отлаживать;
  • GIL приучил не думать о параллелизме;
  • польза только при I/O-задачах, CPU-нагрузка не ускоряется;
  • фреймворки не догнали: Django ORM всё ещё синхронен, Flask тоже.
• Классический кейс — HTTP-запросы: стартуем сотни корутин, ждём ответов, не блокируем интерпретатор.
• Но дисковый I/O, CPU-задачи и другие сценарии не так выигрывают.
• Вывод: чтобы новые фичи 3.14 (free-threading, sub-interpreters) не повторили судьбу async, нужно:
  • чётко объяснять, какие задачи они решают;
  • давать простые API и инструменты отладки;
  • не ждать, пока экосистема «догонит», а сразу внедрять в популярные библиотеки.

• Async в Python пришёл «слишком поздно»: к моменту появления asyncio большинство уже решали задачи I/O через forking, multiprocessing или сторонние библиотеки.
• «Цветные функции» и необходимость переписывать весь код ради async делают его «заразным» и несовместимым с существующими синхронными библиотеками.
• Сложная семантика (event-loop, await, cancellation-исключения), плохая документация и отсутствие понятных best-practice усложняют отладку и поддержку.
• Для большинства задач Python-разработчика async не критичен: WSGI/WSGI-совместимые решения, Celery, Kafka и простое горизонтальное масштабирование покрывают потребности.
• Альтернативы (trio, anyio, gevent) и другие языки (Go, Elixir) предлагают более простые модели конкурентности без «раскрашенных» функций.

• 20+ специалистов из 4 континентов ищут удалённую работу; большинство — full-stack, DevOps, ML/AI и мобильные разработчики.
• Регионы: США (Austin, SF, NYC, Florida), Латинская Америка (Буэнос-Айрес, Богота, Медельин), Европа (Лондон, Осло, Хорватия), Азия (Бангкок, Ханой), Африка (Лагос) и др.
• Ключевые стеки: Rust/Go/Python, React/Node, AWS/GCP, Docker/K8s, LLM/AI-инструменты, iOS/Android, а также редкие — DSP, C++, embedded.
• Готовность к релокации: ~30 % «да», ~60 % «только удалённо», остальные — «возможно при убедительном предложении».
• Уровни: от стажёров и new-grad до 20-летних ветеранов и CTO; многие предоставляют портфолио и рекомендательные письма.

Agent Client Protocol (ACP) — единый стандарт связи между редакторами кода и агентами-разработчиками на базе ИИ.
Протокол в разработке, но уже позволяет строить полезные интеграции.

Зачем ACP?

• Редакторы и агенты сейчас жёстко связаны: каждая пара требует собственной интеграции.
• Это → лишние затраты, ограниченная совместимость и привязка к конкретным интерфейсам.
  ACP, как LSP для языковых серверов, развязывает стороны: агент, реализовав ACP, работает во всех совместимых редакторах, а редактор, поддерживающий ACP, получает доступ ко всей экосистеме агентов.

Как устроено

• Агент запускается как подпроцесс редактора.
• Обмен — JSON-RPC через stdio.
• Используются типы MCP, дополнены собственными (например, для диффов).
• Текст для пользователя — Markdown, без необходимости HTML.

Поддержка

Редакторы:

• Zed
• neovim (через плагин CodeCompanion)

Агенты:

• Gemini
• Скоро — ещё.

• Предложен новый протокол (ACP) для связи агентов-ИИ с IDE/редакторами, плюс библиотеки на Node, Python, Rust и сайт.
• Название ACP вызывает путаницу с уже существующим agentcommunicationprotocol.dev и IBM/Google A2A.
• Некоторые считают, что достаточно расширить LSP или MCP, другие предлагают «Neovim внутри Claude Code», а не наоборот.
• Уже есть первые реализации для Claude Code и Zed, но остаются проблемы с поиском несохранённых файлов и UI-дифами.
• Обсуждают риск фрагментации стандартов и желание, чтобы любой редактор мог подключиться без переписывания под каждого агента.

Кратко:
Инженеры, создающие realtime-аналитику или AI-функции, нуждаются в инфраструктуре данных с современным developer experience (DX). MooseStack от 514 — open-source DX-слой для ClickHouse.

---

Слияние дисциплин

Классические хранилища и озёра строились для аналитиков: SQL, BI-дашборды. Теперь же realtime-данные встроены в продукты и AI-функции, а команды разработки обязаны поставлять их так же быстро, как и обычный код.

• Транзакционные БД (Postgres, MySQL) хороши для разработки, но проваливаются при аналитических нагрузках.
• Облачные аналитические платформы (Snowflake, BigQuery) удобны для пакетных ETL, но не обеспечивают свежесть данных и sub-second ответов, а DX в них устарел.

---

UX-разрыв

Пользователи хотят аналитику за миллисекунды. ClickHouse решает задачу: на порядки быстрее Postgres и дешевле Snowflake/Databricks.

---

DX-разрыв

Разработчики привыкли к локальному циклу «код → тест → CI/CD». В мире данных такого нет: нет локального окружения, медленные итерации, конфликты между data- и software-инженерами.

---

MooseStack

514 выпустили MooseStack — open-source DX-слой поверх ClickHouse:

• Git-native, local-first, everything-as-code.
• Единый язык схем и запросов для всех специалистов.
• Поддержка CI/CD, preview-окружений, автотестов.

• Сторонники «чистого» инженерного подхода считают, что data engineering изначально был частью software engineering, но позже к нему примешались аналитики, знающие лишь SQL/DBT.
• В сообществе виден раскол: одни DE пишут Terraform, CI/CD, Spark и k8s, другие ограничиваются ноутбуками, SQL-запросами и no-code-инструментами.
• Критика Python и SQL как «недостаточно инженерных» языков: динамическая типизация, отсутствие строгих схем и нормального тестирования.
• Название роли «Data Engineer» стало размытым: HR ищут «писателей SQL», а специалисты просят называть их «Software Engineer, Big Data» или «Platform Engineer».
• Сильные практики уже давно используют IaC, версионирование, code review и полноценный SDLC, но таких меньшинство.

grok-code-fast-1 — новая модель xAI для агентного кодинга: быстрая, дешевая, заточена под ежедневную работу.

• Скорость: архитектура с нуля, оптимизация инференса, кеш >90 %. Десятки вызовов инструментов до того, как вы прочтёте первую строку мыслей.
• Цена: 0,20 $/1 M входных, 1,50 $/1 M выходных, 0,02 $/1 M кешированных токенов.
• Языки: TypeScript, Python, Java, Rust, C++, Go.
• Инструменты: grep, терминал, редактирование файлов — «родная» работа в IDE.
• Партнёры: временно бесплатно в Cursor, GitHub Copilot, Cline, Roo Code, Kilo Code, opencode, Windsurf.

Производительность

• 190 токенов/сек, SWE-Bench-Verified 70,8 %.
• Оценки реальными разработчиками: быстро и надёжно для рутинных задач.

• Кто-то хвалит grok-code-fast-1 за скорость и качество, сравнивая с gpt-5-mini, другие считают «быстро, но тупо».
• Основная критика: упор на скорость вместо качества, неточные или вредные изменения кода, сомнительные внутренние бенчмарки.
• Несколько человек жалуются, что модель случайно удаляет код и скрывает кнопки «стоп».
• Подняты этические и экологические вопросы: нелегальные газовые турбины и «обученный нацистский бот».
• Часть пользователей просто рада быстрой бесплатной модели в Cursor/VS Code для простых задач.

Debian 13 «trixie» вышла после двух лет разработки: 14 000 новых пакетов, APT 3.0 по умолчанию и официальная поддержка 64-битного RISC-V.
Версии ПО: GNOME 48, Plasma 6.3, Xfce 4.20, Emacs 30.1, LibreOffice 25.2, ядро 6.12.41 LTS, GCC 14.2, Rust 1.85, Python 3.13, systemd 257.
Поддерживаемые архитектуры: amd64, armhf, arm64, ppc64el, s390x, riscv64. i386 исчез, armel последний релиз.

Обновление из bookworm возможно: конвертируйте sources.list в DEB822 (команда apt modernize-sources появится только в trixie), удалите сторонние пакеты и проверьте, что имена сетевых интерфейсов могут измениться.

Установка: от 64 МБ netboot-ISO до образов Blu-ray; для больших образов рекомендуют BitTorrent или jigdo.

• Некоторые пользователи считают «unstable» (sid) вполне стабильной для ежедневной работы, другие подчеркивают, что всё же бывают серьёзные сбои.
• Многие узнали о новом инструменте extrepo для подключения внешних репозиториев, но на Trixie пока встречаются проблемы с зависимостями.
• Trixie хвалят за «дружелюбие» к пользователю и свежие пакеты, однако NVIDIA-драйверы и CUDA-репы пока не обновлены, что вызывает головную боль.
• Для более новых версий ПО советуют backports, Flatpak или официальные deb-пакеты Mozilla, чтобы не ждать ESR.
• Серверные админы считают Debian лучшим выбором для продакшена, но на десктопе ему иногда не хватает свежести.

Python: The Documentary
На EuroPython показали фрагмент 90-минутного фильма Python: The Documentary от CultRepo; полная версия уже на YouTube.

Фильм рассказывает, как хобби-язык 90-х стал основой ИИ, анализа данных и крупнейших компаний, почти исчез, но выжил благодаря сообществу. Участники: Гвидо ван Россум, Трэвис Олифант, Барри Варшава и другие.

Запись доклада тоже доступна.

• Документальный фильм о Python вызвал тёплые воспоминания: кто-то вспомнил, как перешёл с Perl/Java, кто-то — как язык спас его карьеру.
• Некоторые участники отметили вклад женщин в историю Python и пожалели, что Тим Петерс не участвовал «вживую».
• Часть комментаторов жалуется: «большой» Python теперь ассоциируется с медленным, не типизированным AI-кодом.
• Другие напоминают, что YouTube, Uber и прочие гиганты всё ещё крутятся на Python, и считают критику преувеличенной.
• Всплыли эпизоды о «моржовом операторе» как поводе для отставки Гвидо, а также о том, как Python 2→3 расколол сообщество.

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

• Документальный фильм о Гвидо ван Россуме вызвал противоречивые отзывы: кто-то похвалил прагматизм создателя Python, кто-то остался разочарован.
• Некоторые зрители сравнили его с «Java Movie» и «React-документалкой» и нашли новый фильм слабее.
• Критика касается «слишком глянцевого» монтажа и ощущения «переобожествления» героя.

CLI-агенты: зачем покупать, если можно собрать

CLI-агенты умеют читать код, запускать тесты и править файлы. Готовые решения не знают специфику вашего проекта, поэтому мы собрали собственного агента из открытых инструментов на Pydantic-AI.

Архитектура

• База: Pydantic-AI + LLM
• MCP-серверы (плагины):
  • запуск кода в песочнице
  • актуальная документация библиотек
  • AWS-инструменты
  • поиск в интернете
• Desktop Commander – полный доступ к файловой системе (осторожно!)

Как мы росли

1. Старт: простой CLI-запуск тестов.
2. Интеллект: добавили системные инструкции и распознавание намерений.
3. MCP: подключили песочницу Python, доки, AWS, поиск.
4. Оптимизация: длинные цепочки рассуждений, структурированные ответы.

Полученные выводы

• Прозрачность: видим каждый шаг.
• Контроль: сами решаем, что разрешено.
• Гибкость: легко добавить новый MCP-сервер.

Дальше

• GUI-обёртка, CI/CD-интеграция, автоматические PR.
• Публикация MCP-серверов как open-source.

Собственный агент дешевле, понятнее и точнее подходит под ваши правила.

• Большинство участников хвалят Pydantic AI за отзывчивую команду, лёгкое расширение API и гибкую модель агента без DAG.
• Некоторые жалуются на баги при работе с редкими фичами (Azure OpenAI, стриминг) и предпочитают самописные решения или LiteLLM.
• Есть сомнения в стабильности работы с Pydantic-моделями: кто-то добивается лучших результатов «вручную», минуя библиотеку.
• Обсуждаются альтернативы и затраты: Claude Code дешевле API Sonnet 4, SWE-bench дорог для оценки код-агентов, LiteLLM проще в документации.

Vibe-кодинг глазами ветерана

Эксперимент
2 недели, 40 часов, 5 k строк Python: AI-агент и я пишем микро-игру с алгоритмами A*, Minimax и пр. Цель — проверить, вытесняет ли LLM «искусство программирования».

Процесс

• Промптинг: описываю задачи естественным языком, AI генерирует код.
• Рефакторинг: «сделай класс короче», «добавь тесты» — срабатывает 80 %.
• Отладка: трассировка стека + «почему падает?» — LLM быстро находит баги.
• Архитектура: за меня выбирает структуру пакетов, но я корректирую.

Что понравилось

• Скорость: MVP за 3 вечера.
• Меньше рутины: никаких «import os.path.join».
• Новые идеи: AI предложил кэш-стратегию, которой я не планировал.

Что не так

• «Галлюцинации» API: методы, которых нет в библиотеке.
• Сложные баги: race condition LLM не видит без контекста.
• Читаемость: имена вроде helper_utility_v2 приходится переименовывать.

Выводы

• Junior-девелопер теперь = «человек, который умеет спрашивать».
• Сеньор нужен, чтобы фильтровать, тестировать и нести ответственность.
• Синтаксис умирает, зато растёт ценность системного мышления и prompt-инженерии.

Советы ветеранам

1. Делайте микро-промпты: «добавь docstring» → «добавь пример вызова».
2. Держи CI/CD: автотесты ловят ошибки, которые AI пропустил.
3. Используй AI как пару, а не замену: «покажи diff» вместо «перепиши всё».

Итог
Vibe-кодинг не убивает профессию, а сдвигает фокус: от написания символов к управлению смыслом. Сборочная линия есть, но над ней всё ещё нужен человек с вкусом.

• Участники сравнивают LLM с консалтинговой фирмой: 50 % шанс получить эксперта, 50 % — стажёра; приходится перечитывать каждую строку.
• «Vibe-coding» (генерация без чтения) вызывает опасения: сложно дебажить, нельзя защитить авторские права, а тонкие баги пролезают.
• Опыт показывает: AI полезен в известных языках и задачах (Python, CRUD), но почти бесполезен в нишевых (C/C++ gamedev, Prolog, Haskell).
• Старшие разработчики всё равно нужны: только они могут проверять, направлять и «владеть» кодом, созданным ИИ.
• Возникает вопрос: если не брать джунов, откуда возьмутся будущие сеньоры?
• Предлагают термины вместо «vibe-coding»: «pro-coding», «prompt-coding», «reviewing code».

Байес

$$P(A|B)=\frac{P(B|A)P(A)}{P(B)}$$ Обновляем вероятность гипотезы при новых данных.

def bayes(p_d, p_t_d, p_t_nd):
    p_t = p_t_d*p_d + p_t_nd*(1-p_d)
    return p_t_d*p_d / p_t

Энтропия

$$H(X)=-\sum_x P(x)\log P(x)$$ Измеряем неопределённость распределения.

import numpy as np
H = lambda p: -np.sum(p*np.log(p, where=p>0))

KL-дивергенция

$$D_{\text{KL}}(P|Q)=\sum_x P(x)\log\frac{P(x)}{Q(x)}$$ Сколько бит «лишних» нужно, если вместо истинного распределения $P$ использовать $Q$.

Кросс-энтропия

$$H(P,Q)=-\sum_x P(x)\log Q(x)$$ Используется как лосс в классификации.

Линейная алгебра

Линейное преобразование

$$\mathbf{y}=A\mathbf{x}$$ Матрица $A$ переводит вектор $\mathbf{x}$ в пространство признаков.

Собственные значения и векторы

$$A\mathbf{v}=\lambda\mathbf{v}$$ Направления, вдоль которых преобразование лишь растягивает/сжимает.

SVD

$$A=U\Sigma V^\top$$ Разложение на ортогональные и диагональные матрицы; основа PCA и рекомендательных систем.

Оптимизация

Градиентный спуск

$$\theta_{t+1}=\theta_t-\eta\nabla_\theta J(\theta)$$ Шагаем против градиента, чтобы минимизировать функцию потерь $J$.

Backprop

$$\frac{\partial L}{\partial W^{(l)}}=\delta^{(l)}(a^{(l-1)})^\top$$ Цепное правило для обучения нейросетей.

Функции потерь

MSE

$$\text{MSE}=\frac{1}{n}\sum_i (y_i-\hat y_i)^2$$ Классика регрессии.

Кросс-энтропия

$$L=-\sum_i y_i\log \hat y_i$$ Стандарт для классификации.

Продвинутые темы

Диффузия

$$q(x_t|x_{t-1})=\mathcal N(x_t;\sqrt{1-\beta_t}x_{t-1},\beta_t I)$$ Постепенное добавление шума и обратное восстановление.

Свертка

$$(f*g)[n]=\sum_m f[m]g[n-m]$$ Извлечение локальных паттернов в CNN.

Softmax

$$\text{softmax}(z_i)=\frac{e^{z_i}}{\sum_j e^{z_j}}$$ Превращает логиты в вероятности.

Attention

$$\text{Attention}(Q,K,V)=\text{softmax}\left(\frac{QK^\top}{\sqrt d_k}\right)V$$ Взвешенная сумма значений по релевантности запроса и ключей.

---

Краткий конспект ключевых уравнений ML: от вероятностей до трансформеров, с кодом и интуицией.

• @dkislyuk и @morleytj критикуют формат «списка формул» без связного объяснения и советуют читать оригинальную теорию Шеннона.
• @cl3misch нашёл баг в коде энтропии из-за неинициализированных значений и несоответствие формулы кросс-энтропии.
• @dawnofdusk и @cgadski хвалят полноту материала как удобную шпаргалку для быстрого погружения.
• @bee_rider и @calebkaiser обсуждают применение сингулярных чисел и собственных значений в LLM и LoRA.

Как 20-летний алгоритм помогает понять эмбеддинги трансформеров

Чтобы понять, о чём думает LLM, когда она слышит «Java», нужно разложить внутренние векторы на понятные человеку концепции. Это формулируется как задача dictionary learning: эмбеддинг представляется как разреженная сумма базовых векторов-концептов. В 2023 г. Bricken и др. предложили учить словарь через sparse autoencoder (SAE), отказавшись от классических методов из-за масштабируемости и опасения «слишком сильного» восстановления признаков.

Мы показали, что 20-летний алгоритм KSVD, с минимальными доработками, справляется с миллионами примеров и тысячами измерений. Наивная реализация требовала бы 30 дней; наша версия DB-KSVD ускорена в 10 000 раз и работает 8 минут. DB-KSVD обобщает k-means, но позволяет приписывать объект сразу нескольким «кластерам» (концептам).

Библиотека KSVD.jl доступна из Python:

import torch, juliacall; jl = juliacall.Main
jl.seval("using KSVD")
Y = torch.rand(128, 5000, dtype=torch.float32)
res = jl.ksvd(Y.numpy(), 256, 3)  # словарь 256, sparsity 3

На бенчмарке SAEBench DB-KSVD и расширение MatryoshkaDB-KSVD показывают результаты, сравнимые с SAE, по шести метрикам: восстановление эмбеддингов, разделение концептов, их интерпретируемость и др.

• В чате поделились скрытым гемом — второй половиной двухчасового видео Леланда Мак-Иннеса (автора UMAP) о построении эмбеддингов через пред-преобразования и SVD.
• Участники отметили отличное время публикации: идея пригодилась для текущих задач.
• Основная претензия — авторы не расшифровали сразу аббревиатуры, особенно KSVD, что замедлило чтение.
• Уточнили: KSVD ≠ обычный SVD, это алгоритм разреженного кодирования с избыточным базисом и разреженными активациями.

Как создать инструкцию по установке MCP-сервера

1. Определите тип сервера

   • stdio – локальный процесс.
   • sse – удалённый HTTP-эндпоинт.

2. Соберите метаданные

   • Название, описание, автора, ссылку на репозиторий.
   • Требования: Node.js, Python, Docker и т.д.
   • Порт (для SSE), путь к исполняемому файлу (для stdio).

3. Сформируйте claude_desktop_config.json
   Пример stdio:

   {
     "mcpServers": {
       "my-server": {
         "command": "node",
         "args": ["build/index.js"],
         "env": { "API_KEY": "xxx" }
       }
     }
   }
   

   Пример SSE:

   {
     "mcpServers": {
       "my-server": {
         "url": "http://localhost:3000/sse",
         "headers": { "Authorization": "Bearer xxx" }
       }
     }
   }
   

4. Сгенерируйте инструкцию

   • Установите зависимости (npm i, pip install -r requirements.txt).
   • Скопируйте claude_desktop_config.json в %APPDATA%\Claude\ (Win) или ~/Library/Application Support/Claude/ (macOS).
   • Перезапустите Claude Desktop.

5. Проверьте работу
   Откройте Claude → шестерёнка → Developer → MCP → убедитесь, что сервер “Connected”.

6. Опубликуйте
   Добавьте README.md с шагами выше и примером конфига.

• Пользователи хотят не просто «забронировать», а исследовать: «покажи самые дёшевые окна в Токио за 3 месяца».
• Все сходятся, что полностью автономное бронирование пока ненадёжно: доверие к ИИ низкое, цены скачут, а условия договора надо принимать вручную.
• MCP-серверы рассматриваются как новая «AI-API» — удобно для агентов, но бизнес может быстро закрыть доступ, если это ударит по рекламе и контролю.
• Kiwi и прочие агрегаторы могут зарабатывать на самой продаже билетов и страховках, а не на рекламе, но риски покупки у посредников остаются.
• Пока что MCP-инструменты лучше работают как «умный поиск с последующим подтверждением человека», а не как полностью автономный консьерж.

## Простой RAG с PageIndex

**Цель**  
Показать, как за 5 минут построить полноценный Retrieval-Augmented Generation пайплайн на базе PageIndex.

---

### 1. Установка и импорт

```bash
pip install pageindex openai

import pageindex, openai, os
openai.api_key = os.getenv("OPENAI_API_KEY")

---

2. Загрузка документов

Поддерживаются PDF, DOCX, TXT, MD, PPTX, CSV, JSON.

docs = pageindex.load_documents("data/")
index = pageindex.Index(name="my_docs")
index.add_documents(docs)

---

3. Поиск и генерация

query = "Какие преимущества RAG?"
chunks = index.search(query, top_k=3)

context = "\n".join(c.text for c in chunks)
prompt = f"Используй контекст:\n{context}\n\nВопрос: {query}"

answer = openai.ChatCompletion.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": prompt}]
).choices[0].message.content

print(answer)

---

4. Потоковый чат

chat = index.chat_session(model="gpt-4")
print(chat.ask("Сравни RAG и fine-tuning"))

---

5. Сохранение и переиспользование

index.save("my_docs.pidx")
# index = pageindex.Index.load("my_docs.pidx")

---

Советы

• Для больших объёмов используй batch_size=100.
• Повышай top_k при недостаточном контексте.
• Добавляй metadata={"source": "file.pdf"} для фильтрации.

Готово! Теперь у вас работает RAG без векторных БД и сложной инфраструктуры.

• Критики считают «vectorless RAG» переизобретением семантического чанкинга + иерархического поиска и сомневаются в масштабируемости.
• Основной минус — высокие затраты и латентность: каждый запрос требует прогона LLM по всем документам или их крупным фрагментам.
• Подход может подойти для малого корпуса или офлайн-задач (юрдоки, медкарты), но не для чатов «здесь и сейчас».
• Некоторые предлагают гибриды: ANN-вектора для быстрого отбора, затем LLM-переранжирование.
• Пропущены публичные бенчмарки; сравнение ограничено собственным датасетом MAFIN2.5.

Перешёл в компанию, где стек — Python. Выбор был не из-за языка: Python мне всегда казался гигантским красным флагом. Тем не менее, начинаю к нему привыкать.

Почему я любил Ruby

Ruby — мой первый «язык-любовь»: всё объект, if можно переписать блоками, method_missing позволяет метапрограммировать. Он черпал у Smalltalk и Lisp, и это вдохновляло.

Почему ненавидел Python

Python казался «хуже Ruby» и «ещё хуже Scheme». if — оператор, а не выражение; lambda уродливые; до Python 3 print вообще был оператором. Один «правильный» способ делать всё раздражал.

Типы для нетипизированного

Потом пришёл TypeScript: мощная система типов, narrowing, conditional types. Плохие конструкции языка прощаются статическим анализом.

Я изменился

TypeScript научил: отсутствие match или if-выражения пережить, если компилятор проверит инициализацию. Rust показал, что мутабельность — не зло.

Python изменился

Теперь в Python есть type hints, match с деструктуризацией, а print — функция.

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

CLI-утилитам не место в ~/Library/Application Support

Популярные библиотеки (Python platformdirs, JS env-paths, Rust dirs, Go adrg/xdg) по умолчанию кладут конфиги в ~/Library/Application Support, но это каталог для GUI-приложений. Пользователи ожидают увидеть настройки CLI-программ в ~/.config, как Git, Vim, Tmux и сотни других. Это ожидание закреплено стандартом XDG и принципом «наименьшего удивления».

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

• Неожиданное расположение ломает привычки и усложняет версионирование.
• Даже менеджеры dotfiles (chezmoi, dotbot, yadm, rcm, GNU Stow) игнорируют ~/Library/Application Support, что подтверждает: сообщество считает ~/.config единственным разумным местом для конфигов CLI-утилит на macOS.

• Автор утверждает, что CLI-утилиты macOS должны хранить конфиги в ~/.config по XDG, но участники показывают: ни одна поставляемая с macOS утилита этого не делает.
• Большинство считает XDG спецификацией для Linux/Unix-сред и не видят оснований навязывать её macOS, у которой есть собственные места: ~/Library/Preferences и ~/Library/Application Support.
• Разработчики CLI-инструментов, портированных с Linux, действительно часто используют ~/.config, что вызывает у местных пользователей ощущение «плохого порта».
• Предлагаются компромиссы: использовать XDG-переменные, если они заданы, или делать симлинки между ~/.config и ~/Library/Application Support.
• В Rust-экосистеме крейт dirs-rs игнорирует XDG на macOS; участники обсуждают создание форка, который бы следовал спецификации.

TuneD — служба тонкой настройки Linux.

• Отслеживает устройства через udev, применяет профили, управляется из CLI и D-Bus.
• Поддерживает sysctl, sysfs, параметры ядра, плагины.
• Работает без демона на ограниченных системах.
• Всё хранится в одном профиле, без разбросанных скриптов.

Профили

• Наследуются: общий HTTP-шаблон → Apache, Nginx.
• Полный откат изменений.
• Готовые пресеты: высокая пропускная способность, низкая латентность, энергосбережение, SAP, dBase и др.

Документация

• Старая: Fedora Power Management Guide.
• Новая: GitHub.
• Презентация: DevConf 2019.

Скачать
GitHub releases.

Баги
GitHub issues.

Разработка
GitHub.
PR или письма на power-management@lists.fedoraproject.org.

Лицензия
GPL v2+.

• TuneD хвалят за экономию до 40-55 Вт и удобство на рабочих станциях, но на серверах результат «50/50»: иногда отключают и переходят на собственные скрипты.
• Есть адаптер под power-profiles-daemon, поэтому переключать профили можно из GNOME/KDE.
• Критика: дефолтные настройки неверно биндят IRQ для сети, а сам демон написан на Python, что вызывает сомнения в «производительности» инструмента для управления производительностью.
• Нет встроенного ограничения заряда батареи (как в TLP), поэтому для ноутбуков TuneD может быть не идеален.
• Пользователи хотели бы утилиту, которая после установки Linux сразу показывает, что не работает (suspend, GPU, Wi-Fi, диск), но такой «one-shot» диагностики пока нет.

Цветовое пространство — это «карта» всех возможных цветов, которую может воспроизвести устройство.

1. Цвет ≠ свет

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

2. Глаз как камера

Сетчатка содержит три типа колбочек: S, M, L. Их сигналы превращаются в три числа (XYZ), описывающие цвет.

3. XYZ и «лошадиная подкова»

Международная система CIE-XYZ строит 2D-диаграмму всех видимых цветов. Внутри неё — треугольники sRGB, P3 и Rec.2020: чем больше треугольник, тем больше охват.

4. RGB — не просто «красный, зелёный, синий»

Каждое пространство задаёт точные координаты своих «красного», «зелёного» и «синего». Перекрасить изображение между пространствами можно матрицей 3×3, но если цвета выходят за границы треугольника, приходится «сжимать» их (rendering intent).

5. Гамма-кривая

Люди чувствуют свет нелинейно. Поэтому sRGB и большинство RGB-пространств применяют гамму ≈ 2.2, чтобы экономить биты и не хранить невидимые тени.

6. Не только RGB

• HSV/HSL — удобны для палитр, но не физически точны.
• LAB/LCH — основаны на восприятии, позволяют менять яркость без сдвига оттенка.
• CMYK — субтрактивная модель печати, зависит от типа бумаги и чернил.

7. Профили и ICC

Файл .icc описывает, как устройство интерпретирует числа. Без профиля «255, 0, 0» может быть ярко-красным на одном экране и тусклым на другом.

8. Практические советы

• Работайте в широком пространстве (P3/Rec.2020), экспортируйте в sRGB для веба.
• Проверяйте «out-of-gamut» перед печатью.
• Не используйте HSL для научных задач.

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

agent-c — сверхлёгкий AI-агент от bravenewxyz.
Проект открыт, код на GitHub.

• 4 КБ-агент на Си вызывает OpenRouter через curl и исполняет команды, что вызывает шутки о «русской рулетке» и безопасности.
• Критика: сжатие UPX, отсутствие проверок ошибок, жёстко заданные константы, popen вместо libcurl.
• Лицензии обсуждают от «Copy me» до CC0, BSD, Apache, GPL и WTFPL.
• Некоторые предлагают запускать под отдельным пользователем или в Docker, локально через Ollama/LM Studio.
• Промпт заставляет агента говорить как Наполеон Динамит («Gosh!», «Sweet!»).
• Сравнивают с Rust-версией «alors» и оффлайн-Python-примером на 44 строки.

sping — терминальный мониторинг задержек HTTP/TCP с живыми графиками. Установка: pip install service-ping-sping.

Быстрый старт

sping google.com                 # HTTP
sping tcp://google.com:80        # TCP
sping https://api.example.com -i 0.5 -c 20
sping example.com --json -c 5

Возможности

• HTTP/HTTPS/TCP, разбивка по фазам (DNS, TLS, запрос, ответ).
• Авто-обнаружение выбросов по MAD (6× медиана).
• Пороги warning/critical, выбор IPv4/IPv6, кэш DNS.
• Процентили p50-p99, экспорт JSON, 8 цветовых тем.
• Bearer/Basic-аутентификация, кастомный User-Agent.

Примеры

sping api.example.com -X POST --body --auth "bearer:token"
sping tcp://localhost:5432 -i 0.1
sping example.com --warn 100 --crit 500 --percentiles

Ключи

-i интервал, -c число запросов, --timeout, --ipv4/--ipv6, --resolve-once, --body, --no-keepalive, --insecure, --warn/--crit, --percentiles, --palette <theme>.

• Пользователи хвалят визуальный ping-утилиту sping, но предлагают переписать её на Go/Rust для статического бинарника без зависимостей.
• Автор подтвердил, что проект полностью сделан с помощью ChatGPT и Claude, а README «украшен» эмодзи.
• Найдены мелкие баги: ошибка палитры цветов и сбой при выводе финального резюме.
• Некоторые сравнивают инструмент с mtr, tracepath и nping --tr, отмечая, что нужен более дружелюбный аналог.

Как заменить код функции «на лету»

Python позволяет переписывать тело функции во время работы программы:

1. Берём исходник новой функции как строку.

   new_src = "def f(x): return x * 2"
   

2. Компилируем:

   code = compile(new_src, "<magic>", "exec")
   

3. Выполняем в нужном пространстве имён:

   ns = {}
   exec(code, {}, ns)
   

4. Подменяем старую функцию:

   f = ns["f"]
   

f(21) теперь возвращает 42.

Зачем это нужно

Такой трюк позволяет LLM-агентам генерировать и сразу запускать код с доступом к текущему контексту. Это удобно для ToolBot, но открывает огромную дыру в безопасности: любой сгенерированный код получает доступ ко всем переменным процесса.

• @breuleux показал jurigged — библиотеку для горячей перезагрузки только изменённых функций без перезапуска модулей.
• Участники сравнили приём с monkey-patching, Lisp-овой «код как данные» и REPL, отметив плюсы и отладочные грабли (стек-трейсы вида <magic>).
• Обсуждали, где ещё работает такое: JVM/CLR, Erlang, динамические библиотеки в C/C++ и игровые движки.
• Кто-то считает это мощным, кто-то — анти-паттерном; всплыли ссылки на autoreload, forge и swanky-python.
• Наконец, всех достала навязчивая привязка любой темы к AI-хайпу.

clearcam — добавляет к любой RTSP-камере или iPhone детекцию, трекинг объектов и push-уведомления.
Работает на Raspberry Pi, Linux, macOS, Windows; Python 3.8+.

Ключевые функции

• Детекция людей, животных, машин, посылок (YOLOv8).
• Трекинг объектов между кадрами.
• Уведомления в iOS/Android (Firebase).
• Запись коротких клипов при событии.
• Web-интерфейс для просмотра и настройки.

Быстрый старт

git clone https://github.com/roryclear/clearcam
cd clearcam
pip install -r requirements.txt
python clearcam.py --source rtsp://user:pass@ip/stream

Настройка

• config.yaml: камеры, классы объектов, чувствительность, токен Firebase.
• Telegram-бот для команд «/arm», «/disarm».

Примеры

• Дом: уведомление, если кто-то вошёл во двор.
• Офис: отслеживание доставленных посылок.

• Обсуждали два решения: новый проект Clearcam и известный Frigate; Clearcam проще ставится, но удалённый просмотр и уведомления требуют подписки, тогда как у Frigate всё бесплатно.
• Пользователей смущает, что Android-версия Clearcam пока требует регистрации через iOS и Apple Pay.
• Ищут камеры без шпионского ПО: советуют Axis, Reolink, Ubiquiti, а также самоделки на open-source прошивке Thingino.
• Разбирались, как детектировать машины, не остановившиеся у знака «стоп»: предложили измерять скорость между двумя точками и задавать порог.
• Выяснили, что термин «CCTV» всё ещё используют для любых камер наблюдения, хотя технически это уже IP-видео.

Как собрать код-агента: бесплатный воркшоп

Материалы и исходники: GitHub

Суть

• Агент — это 300 строк кода, работающие в цикле, которому просто подаются токены LLM.
• Поняв принцип, вы перестанете быть потребителем ИИ и станете его продюсером, автоматизируя свою работу.

Зачем

• В 2025 г. знание, как создать агента, стало фундаментальным навыком, как понимание primary key.
• Работодатели ищут тех, кто может оркестрировать ИИ внутри компании.
• Во время Zoom-звонка ваш агент может уже писать код, который вы только обсуждаете.

Что будет на воркшопе

• Live-сборка агента прямо во время доклада.
• Объяснение внутреннего устройства: цикл, токены, промпты.
• Практика: агент строит агента под диктовку.

Дальше

• Если хотите, чтобы я провёл такой воркшоп у вас в компании — пишите.

• Команда Princeton SWE-bench выложила компактный (~100 строк) агент для SWE-bench.
• Пользователи жалуются на перегруженный AI-слайд-стиль и избыточные картинки, которые мешают чтению.
• Спор о необходимости отдельных инструментов: многие действия можно делать через bash, но специализированные утилиты экономят токены и повышают надёжность.
• Обсуждают, что «токены = деньги» и что локальные модели могут изменить ситуацию.
• Критика: пост показывает лишь базовый подход, не раскрывая продвинутые темы (sandbox, snapshot, prompt-инженерия).

Краткий итог тестов LLM для личных задач

• Цель: найти быструю и дешёвую модель для простых вопросов по Rust, Python, Linux и быту.
• Данные: 130 реальных запросов из bash-истории, разбитые на программирование, администрирование, объяснения, общие знания.
• Платформа: OpenRouter через собственный Rust-клиент ort.
• Тестовые модели: Claude-4 Sonnet, DeepSeek-chat-v3, DeepSeek-r1, Gemini 2.5 Flash/Pro, Kimi-k2, GPT-OSS-120B, Qwen3 235B (обычный и thinking), GLM-4.5, а также Mercury-Coder, Devstral, Qwen3-Coder для кода.

Выводы

• Почти все модели справляются; различия в качестве минимальны.
• Критерии победы: цена и скорость. Запросы стоят доли цента, но латентность варьируется в десятки раз.
• Закрытые модели не лидируют: Gemini Pro самый дорогой и многословный; Flash быстрее всех, но не всегда лучше.
• Режим «рассуждений» почти не нужен, кроме творческих заданий (стихи).
• Победители по категориям
  • Программирование: Mercury-Coder (сверхбыстрый диффузионный), DeepSeek-r1, GLM-4.5.
  • Сисадмин: Gemini 2.5 Flash.
  • Объяснения: Qwen3 235B.
  • Общие знания: GPT-OSS-120B.

Инсайт: для рутинных задач выбирайте самую дешёвую и быструю модель, которая «достаточно хороша».

• Google Gemini 2.5 Flash признан «рабочей лошадкой»: быстро, дёшево, мультимодален и способен пережёвывать 100 k запросов за €30.
• Большинство участников жалуются на «сговор» моделей: при творческих задачах 6 из 11 LLM выдают один и тот же ответ, что убивает креатив.
• Локальный запуск: на Mac Mini 64 ГБ уверенно работают модели < 32 B; фаворит — gpt-oss-20b (11 ГБ RAM) и семейство Qwen 3.
• Для выбора «одной на всё» многие выбирают deepseek-chat-v3-0324 как компромисс скорость/цена/качество.
• Трения с API: OpenAI требует KYC, Claude доступен не везде, поэтому кто-то использует Kagi, Perplexity или OpenRouter, чтобы «пощупать» все модели без лишних ключей.

• Камера – Alkeria Necta N4K2-7C, 4096×2 Bayer, 16-бит raw.
• ROI – энергия ∂I/∂x / (0.1·max(I)+|∇I|); 99-й перцентиль по блокам, порог 1.5× минимума.
• Скорость – сравниваем два зелёных канала Bayer-сдвигами ±7 px, подпиксельный пик методом итеративного Гаусса.
• Ресэмплинг – интерполяция по скорости, чтобы не растянуть/сжать объект.
• Демозаик – bilinear + коррекция полос.
• Полосы – вычитаем медиану по строкам.
• Шум – Gaussian + bilateral фильтр.
• Косой кадр – Hough-прямые → угол → поворот.
• Цвет – калибровка по чекеру X-Rite.
• Код – Python + NumPy + OpenCV, «vibe-coding» в Cursor.

• Пользователи делятся опытом: кто-то пробовал сканировать деревья дроном, кто-то делает slit-scan-анимации вручную, а кто-то вспоминает сканеры и старые цифровые спины.
• Обсуждаются промышленные применения: сортировка продуктов на конвейере, фото-финиш, спутники и даже медицинская ОКТ.
• Рассказывают, как почти любую камеру можно превратить в line-scan, выставив только одну строку пикселей и получив 60 000 FPS.
• Показывают примеры снимков из окна поезда и спорят, насколько реально «отсканировать» часовую поездку целиком.
• Отмечают художественный эффект: поезд застыл между полосами цвета, а движущиеся части искажаются, как у спортсменов на фото-финиша.

spaCy — промышленная библиотека NLP на Python.
Быстрая, точная, поддерживает 70+ языков.

Основное

• Установка

  pip install -U spacy
  python -m spacy download en_core_web_sm
  

• Быстрый старт

  import spacy
  nlp = spacy.load("en_core_web_sm")
  doc = nlp("Apple is looking at buying U.K. startup for $1 billion")
  for ent in doc.ents:
      print(ent.text, ent.label_)
  

Возможности

• токенизация, POS-теги, синтаксис, NER
• готовые модели CNN/Transformer
• обучение и дообучение
• интеграция с PyTorch, Transformers, FastAPI
• GPU/Apple Metal

Примеры

• NER: выделение имён, дат, денег
• Matcher: поиск паттернов
• Projects: end-to-end пайплайны
• spaCy LLM: LLM-интеграция без кода

Ресурсы

• Документация
• Интерактивный курс
• Демо
• Discord

• В эпоху LLM традиционный NLP (SpaCy) всё ещё нужен: дешевле, быстрее, работает на обычном железе и не требует постоянной оплаты провайдеру.
• Участники хвалят SpaCy за отличный API, скорость, надёжность NER и удобство пайплайнов; активно используют в enterprise, RAG-метриках и даже на Raspberry Pi.
• Некоторые задачи (классификация, сентимент) LLM решают хуже и дороже, поэтому возвращаются к дискриминативным моделям.
• Сообщество отмечает, что проект немного сократился (v4 задерживается), но библиотека по-прежнему поддерживается и считается недооценённой.

manim — движок анимации от 3Blue1Brown для создания пояснительных математических видео.
Python-библиотека превращает LaTeX-формулы и геометрические объекты в плавные сцены, которые можно рендерить в Full HD или 4K.

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

• Объектно-ориентированный API: создаёте Mobject-ы (Math-Objects) и анимируете их методами .animate, .play, .transform.
• Встроенные шаблоны: графы, векторы, интегралы, матрицы, 3D-сцены.
• LaTeX-рендеринг: компилирует формулы в реальном времени.
• GPU-ускорение (OpenGL) для сложных сцен.
• CLI и Jupyter: запускайте manim -pql scene.py или интерактивно в ноутбуке.

Установка

pip install manim
# или
conda install -c conda-forge manim

Минимальный пример

from manim import *

class HelloMath(Scene):
    def construct(self):
        eq = MathTex(r"\int_{-\infty}^{\infty} e^{-x^2} dx = \sqrt{\pi}")
        self.play(Write(eq))
        self.wait()

Ссылки

• Документация
• Discord-сервер
• Галерея примеров

• Современные LLM отлично генерируют код Manim, экономя время при создании математических видео.
• Пользователи хвалят красоту и понятность роликов 3Blue1Brown и сами делали успешные презентации.
• Актуальная версия библиотеки — community-форк ManimCommunity/manim.
• Ищут аналоги Manim для общих инфографик и моушен-графики (MotionCanvas.io, After Effects и др.).
• Некоторые жалуются на старые проблемы: kwargs-итис и отсутствие типов.
• Есть эксперименты с интерактивной 3D-графикой и автоматическим озвучиванием видео.

Стек для Python-статики: uv + Caddy + Docker

Я почти полностью перешёл на uv — он быстрый, удобен и сам ставит нужный Python. Статические сайты собираю Python-скриптами, а раздаю через Caddy в многоступенчевом Docker-контейнере.

Пример на sus

Dockerfile (сжато):

FROM ghcr.io/astral-sh/uv:debian AS build
WORKDIR /src
COPY . .
RUN uv python install 3.13
RUN uv run --no-dev sus

FROM caddy:alpine
COPY Caddyfile /etc/caddy/Caddyfile
COPY --from=build /src/output /srv/

1. Берём образ с uv, копируем код.
2. uv ставит Python 3.13 и зависимости, запускает sus, который кладёт сайт в /output.
3. Вторая стадия — лёгкий Caddy. Копируем конфиг и готовые статические файлы в /srv.

Caddyfile минимален:

:80
root * /srv
file_server

Запуск:

docker build -t sus .
docker run -p 80:80 sus

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

• Почти все комментаторы считают выбранный стек (Docker, uv, Caddy, Coolify) избыточным для статического личного сайта.
• Критика сводится к тому, что достаточно «HTML → Nginx/Apache» или даже «HTML → FTP».
• Автор отвечает: хотел остаться в экосистеме Coolify ради единого CI/CD и «zero-SSH» деплоя.
• Некоторые предлагают минимальные Dockerfile (nginx:alpine + COPY) или вообще отказаться от контейнеров.
• Обсуждение выродилось в дискуссию о «культуре овер-инжиниринга» и самоучках, использующих сложные инструменты без понимания базовых.

LabPlot — бесплатное кроссплатформенное ПО с открытым кодом для визуализации и анализа данных.

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

• Качественные графики и интерактивные диаграммы в пару кликов
• Статистика, регрессия, аппроксимация и фитинг пиков
• Интерактивные блокноты Python, R, Julia и др.
• Извлечение данных из изображений и поддержка потоковых данных
• Импорт/экспорт множества форматов
• Windows, macOS, Linux, FreeBSD, Haiku

Свежие новости

• 2.12.1 (18 авг 2025) — мелкие улучшения и исправления
• 2.12 (28 апр 2025) — крупное обновление после долгой разработки
• Дек 2024 — обновлённое руководство пользователя

Скачать | Возможности

• Участники обсуждают LabPlot как FOSS-альтернативу Origin/JMP/Tableau для научного графика.
• Сравнивают: гибкость ggplot2, устарелость Excel/SAS, удобство GUI для не-программистов.
• Плюсы: drag-and-drop, встроенный импорт CSV/TSV, лицензия GPLv2+.
• Минусы: пока только SQLite, нет прямого REST/S3/Iceberg, неясно, как быстро копировать стили.
• Целевая аудитория — инженеры и учёные, которым нужен GUI-построитель графиков без кода.

В JavaScript "🤦🏼‍♂️".length == 7 — не ошибка, а результат подсчёта UTF-16 кодовых единиц.
Эмодзи состоит из 5 скалярных значений Unicode, но в UTF-16 они занимают 7 code units:

• 🤦 U+1F926 → 2
• 🏼 U+1F3FC → 2
• ZWJ U+200D → 1
• ♂ U+2642 → 1
• VAR-16 U+FE0F → 1

Итого 7 — именно это и возвращает .length.

Другие языки считают по-своему:

• Python 3 → len("🤦🏼‍♂️") == 5 (кодовые точки, но допускает суррогаты).
• Rust → "🤦🏼‍♂️".len() == 17 (байты UTF-8).
• Swift → "🤦🏼‍♂️".count == 1 (расширенный графем-кластер).

Каждый подход отвечает на свой вопрос: «сколько code units / bytes / графем». Ни один не универсален; выбор зависит от задачи.

• Обсуждение вокруг статьи показало, что «длина строки» не имеет единого определения: бывают байты, UTF-16/UTF-32 код-юниты, скалярные значения Unicode и расширенные графем-кластеры.
• Пользователи жалуются, что разные языки и API возвращают разные числа для одного и того же эмодзи, что ломает UI-ограничения, индексы БД и обработку текста.
• Часть участников считает, что нужно явно различать «длину для хранения», «длину для отображения» и «длину для человека»; другие мечтают вернуться к чистому ASCII.
• Примеры кода на Java, Python, Raku и JS показывают, как получить каждый из вариантов длины, но подчеркивают отсутствие общего стандарта.
• Итог: «length» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.

uv format — экспериментальная команда в uv для форматирования кода. Под капотом вызывает Ruff, но не требует отдельной установки.

Как начать

# форматировать текущий проект
uv format

# проверить, без изменений
uv format --check

# только нужные файлы
uv format src/ tests/

Передача аргументов Ruff

Всё, что идёт после --, уходит напрямую в Ruff:

# исключить файлы
uv format -- --exclude="*_pb2.py"

# задать длину строки
uv format -- --line-length 100

Пока функция флажком --preview, но уже позволяет обойтись без отдельного бинарника ruff.

• Пользователи спорят: стоит ли встраивать форматирование (ruff format) в uv или это «feature-creep».
• Одни рады единой команде uv format, упрощающей жизнь новичкам и командам; другие требуют оставить инструменты раздельными, как в UNIX-way.
• Создатели подчеркивают: ruff и uv не сливаются; uv format лишь удобный алиас, аналогичный cargo fmt.

Python 3.10 добавил сопоставление с образцом, которое использует isinstance.
ABC с __subclasshook__ могут подменять проверку типа, поэтому:

class NotIterable(ABC):
    @classmethod
    def __subclasshook__(cls, C):
        return not hasattr(C, "__iter__")

match x:
    case NotIterable(): ...

работает — 10 считается NotIterable, строки и списки — нет.

Аналогично можно «матчить» по наличию атрибутов:

class DistanceMetric(ABC):
    @classmethod
    def __subclasshook__(cls, C):
        return hasattr(C, "distance")

и деструктурировать:

match x:
    case DistanceMetric(distance=d): ...

Динамически создаём комбинаторы:

def Not(cls):
    class _Not(ABC):
        @classmethod
        def __subclasshook__(_, C):
            return not issubclass(C, cls)
    return _Not

n = Not(DistanceMetric)
match x:
    case n(): ...

Синтаксис не позволяет писать Not(DistanceMetric)() прямо в case, но сохранив сгенерированный ABC в переменную, обходим ограничение.

• btown показал «трюк» с rrshift, позволяющий делать цепочки вида x >> f >> g без изменения левой части.
• Большинство участников критикуют реализацию pattern matching: неочевидное поведение имен-констант, лишняя сложность, отсутствие общих константных паттернов.
• Некоторые считают match-case полезным для структурной проверки типов, но просят линтеры/semgrep-правила, чтобы запретить его в кодовой базе.
• Обсуждаются и другие «преступления»: предложение {/} для пустого множества, метаклассы, меняющие isinstance, и «goto-подобная» неявность.

Fastly: боты для ИИ атакуют сайты до 39 000 запросов в минуту
CDN-провайдер зафиксировал всплеск автоматического сканирования, когда модели собирают данные для обучения.

• Пиковая нагрузка: 39 000 обращений/мин (≈ 650 в секунду)
• Основной инструмент: библиотека python-httpx, User-Agent «ImagesiftBot»
• Цели: медиа-файлы, API-документация, старые URL-ы
• Последствия: рост счёта за трафик и риск DDoS.

Рекомендации Fastly: фильтровать по User-Agent и ASN, ставить rate-limit, использовать WAF.

• AI-компании массово и агрессивно скрапят сайты, игнорируя robots.txt и rate-limits, что приводит к сбоям, росту трат и вынужденному закрытию доступа.
• Пострадавшие владельцы маленьких ресурсов вынуждены ставить Cloudflare, Anubis, honeypot-ловушки и полностью банить ботов, ухудшая опыт обычных пользователей.
• Часть участников считает проблему не технической, а регуляторной: корпорации сознательно нарушают правила, полагаясь на армию юристов.
• Некоторые предлагают добровольно отдавать данные пакетами (tar-файлы), но боты даже официальные каналы скачивания игнорируют.

NetHack при сборке с -DMAIL и OPTIONS=mail может уведомлять о новой почте: демон приносит свиток, при чтении запускается MAILREADER.
Я играю в Emacs-версию и не хочу выходить из неё, поэтому настроил связку mu4e ↔ NetHack.

mu хранит письма в maildir, а NetHack ждёт mbox. Проверяем, появились ли письма за последние 5 минут, и «трогаем» файл /tmp/nh.mbox:

import mailbox, pathlib, os
from datetime import datetime, timedelta

MAILDIR = os.path.expanduser("~/Mail/personal/INBOX")
MBOX = "/tmp/nh.mbox"

maildir = mailbox.Maildir(MAILDIR)
for msg in maildir:
    if datetime.fromtimestamp(msg.get_date()) > datetime.now() - timedelta(minutes=5):
        pathlib.Path(MBOX).touch()
        break
maildir.close()

Читаем почту через mu4e:

emacsclient -n --eval "(progn (require 'mu4e) (mu4e-context-switch nil \"Personal\") (mu4e-search-bookmark \"maildir:/personal/INBOX AND flag:unread\"))"

emacsclient запускает уже работающий Emacs, избегая блокировки базы mu.

• Участники восторгаются креативной интеграцией «реального мира» в NetHack через отправку почты прямо из игры.
• Вспомнили опыт Miiverse в Wind Waker Wii U и предложили добавить такую фичу в Civilization.
• Подняли вопрос безопасности: корректно ли роняются привилегии перед вызовом mail-команды; подтвердили, что CVE по этой теме уже были.
• Emacs- и Vim-пользователи поделились советами, как постепенно осваивать Emacs, начиная с одного юз-кейса.
• Обсудили альтернативные roguelikes: Slashem, Dungeon Crawl Stone Soup и RimWorld.

DiffMem — хранилище памяти для диалоговых ИИ-агентов на базе Git.
Использует коммиты как «снимки» контекста: каждое сообщение = отдельный diff, история полностью версионируется.
Поддерживает ветвление диалогов, откат к любой точке и слияние веток без потери данных.
Работает как лёгкая библиотека Python: pip install diffmem, далее diffmem init, diffmem commit, diffmem checkout.
Внутри — обычный репозиторий Git, поэтому можно пушить на GitHub, делать PR и использовать все привычные инструменты.

• Пользователь предложил заменить векторные БД на «агентивный» ретривал: LLM сама выбирает нужные файлы из аннотированного списка; для сотен документов это проще и точнее, чем классический RAG.
• Критика: такой подход не решает задачи семантического поиска в больших пространствах, для которых и создавались векторные БД.
• Поддержка: git-файлы удобны для малого объёма (≈100 МБ), а BM25/Lucene/FAISS-flat можно использовать как быструю альтернативу.
• Предложены улучшения: post-commit-хуки для обновления индекса, гибридные поиски, MCP-сервер, временные knowledge-graph.
• Автор признаёт, что это PoC для «памяти агентов», а не полноценная замена векторных БД; при интересе готов довести до продакшена.

f-строки: быстрый справочник

Числа

number = 4125.6
percent = 0.3738

Результат	Шаблон
4125.60	{number:.2f}
4,125.60	{number:,.2f}
04125.60	{number:08.2f}
4125.60	{number: 8.2f}
4.1e+03	{number:.2g}
37%	{percent:.0%}

• .2f — 2 знака после запятой
• , — разделитель тысяч
• 08.2f — 8 символов, ведущие нули
• .2g — 2 значащие цифры

Целые

number = 10

Результат	Шаблон
0010	{number:04d}
10	{number: 4d}
10	{number:,}
1010	{number:b}
a	{number:x}
A	{number:X}
0xa	{number:#x}
000a	{number:04x}
0000_1010	{number:09_b}

• 04d — 4 позиции, ведущие нули
• b, x, X — двоичный, шестнадцатеричный
• _ — разделитель разрядов

Строки

string = "Python"

Результат	Шаблон
Python	{string:>20}
Python	{string:<20}
Python	{string:^20}
0000Python	{string:0>10}

• >, <, ^ — выравнивание
• 0> — заполнение нулями

Любые объекты

Модификатор	Пример	Результат
!s	{expr!s}	строковое представление
!r	{expr!r}	repr()
!a	{expr!a}	ASCII-экранирование
=	{expr=}	expr=repr(expr)
= !s	{expr=!s}	expr=str(expr)
= .2f	{expr=:.2f}	expr=4.00

Используйте = для самодокументирующих выражений.

• Автор выложил новый онлайн-инструмент для подбора f-строк и упомянул свой чит-лист.
• Часть участников считает, что f-строки стали слишком сложными и перегружены DSL, уступая простоте % или rjust().
• Другие защищают f-строки за контекстное размещение переменных и читаемость, особенно при отладке через f"{var=}".
• Обсуждались альтернативы (printf, Rust, C-style), а также вопросы динамической сборки строк и необходимости string.format.

PlutoPrint — библиотека Python для генерации PDF и изображений из HTML, работает на базе PlutoBook.
Установка: pip install plutoprint.

Основные возможности

• HTML → PDF/PNG/JPEG — одна строка кода.
• CSS/JS — полная поддержка современных стандартов.
• Шаблоны — Jinja2, Django, Flask и др.
• Пакетная обработка — асинхронный режим.
• Docker-образ для быстрого деплоя.

Быстрый старт

from plutoprint import PlutoPrint

pp = PlutoPrint()
pp.html_to_pdf("report.html", "report.pdf")

Параметры

• format: pdf, png, jpeg
• width/height, orientation, margin, header/footer, dpi

Примеры

• Отчёты, чеки, инвойсы, почтовые этикетки, скриншоты страниц.

Лицензия

MIT.

• Пользователи сравнивают PlutoPrint с WeasyPrint, Puppeteer и Typst: новый движок на C++ обещает быть быстрее и легче по памяти, но покрывает не весь CSS.
• Рекомендуют прогнать тесты с print-css.rocks и проверить прод-качество (проблемы с thead, page-break-inside и т.д.).
• Puppeteer даёт полную поддержку веб-платформы, но требует Chromium и много RAM, особенно для 200-500-страничных PDF.
• Есть вопросы по flexbox, SVG, оглавлению, поддержке Markdown и крэшу на macOS.
• Несколько человек рассматривают PlutoPrint как замену wkhtmltopdf и fpdf, автор открыт к спонсорству.

pytype — статический анализатор типов для Python от Google.
Проверяет аннотации и выводит типы без их явного указания.
Устанавливается через pip install pytype; запуск — pytype file.py.
Поддерживает 3.8–3.12, Linux/macOS.
Конфигурируется в setup.cfg или pyproject.toml.

• Google официально прекращает разработку pytype; бывшие разработчики считают это правильным, но грустным концом эпохи.
• Pytype выделялся межфункциональным анализом потока типов и выводом типов для неаннотированного кода, что критично для больших кодовых баз Google.
• Причина закрытия — сокращение команды Python в Google в 2024 г.; альтернативы: mypy, Pyright, Pyrefly и новый «ty» от Astral.
• Сообщество обсуждает, что mypy слишком медленен для монорепозиториев Google, а Rust-решения ограничивают поддержку архитектур.
• Общий вывод: переходите на Pyright или ждите зрелости ty, но не ждите продолжения pytype.

Зачем нужен семантический слой и как собрать его на DuckDB

Когда не нужен

• Один инструмент аналитики (BI, ноутбук или приложение).
• Метрики тривиальны: COUNT, SUM, AVG.
• Все агрегаты уже материализованы в таблицах.

Зачем нужен

1. Единое место определения метрик – версионируемые YAML-файлы с бизнес-логикой, которые читают BI, ноутбуки, веб-приложения, AI.
2. Кеш и безопасность – быстрые ad-hoc-запросы без переноса данных, ролевая безопасность через API.
3. Согласованность – KPI «Выручка» описан один раз и не дублируется в каждом инструменте.

Минимальный пример

• metrics.yaml – 30 строк: название, SQL-выражение, формат, описание.
• run.py – 40 строк на Ibis + DuckDB: читает YAML, строит запрос к 20 млн записей NYC Taxi, возвращает DataFrame или SQL.

Как работает

import ibis, yaml, duckdb
ibis.options.interactive = True
con = ibis.duckdb.connect("nyc_taxi.ddb")
taxi = con.table("trips")

with open("metrics.yaml") as f:
    metrics = yaml.safe_load(f)

revenue = metrics["total_revenue"]["sql"]
result = con.sql(revenue).to_pandas()

YAML:

total_revenue:
  sql: "SELECT SUM(fare_amount) FROM trips"
  format: currency
  description: "Общая выручка"

Итог
Семантический слой решает проблему дублирования логики и ускоряет аналитику, когда данные и потребители разнообразны. Полный код – в репозитории semantic-layer-duckdb.

• Семантический слой — это абстракция, переводящая технические запросы в термины, понятные бизнес-пользователям, и обеспечивающая единые метрики, джойны и логику.
• Внедрение требует капитальных усилий: аналитики спешат сделать отчёт «здесь и сейчас», а не выделять время на переиспользуемую логику.
• Некоторые считают его «ORM для BI» или «VIEW на стероидах», но он шире: позволяет динамически компоновать представления без повторных вычислений.
• Инструменты варьируются от YAML-файлов до языков вроде Malloy; многие мечтают о встроенной поддержке в DuckDB или Looker-like BI.
• Главный риск — преждевременная абстракция; неправильные метрики закрепляются и тормозят развитие.

Positron — бесплатный IDE для дата-сайенса, поддерживающий Python и R.
Скачать

Продукты

• Enterprise: Posit Connect, Workbench, Package Manager
• Cloud: Posit Cloud, Connect Cloud, shinyapps.io

Open Source

• IDE: Positron, RStudio, RStudio Server
• Библиотеки: Tidyverse, ggplot2, dplyr, Quarto, Shiny, vetiver
• Интеграции: dbplyr, sparklyr, googlesheets

Истории клиентов

• Suffolk, Trillium, Unity Health, NASA, Dow

Партнёры

• Платформы: Snowflake, Databricks, SageMaker
• Облака: AWS, Azure, GCP

• Пользователи хвалят Positron за плавный переход из RStudio/VSCode и улучшенные возможности DS, но жалуются на отсутствие inline-графиков в Quarto и медленное внедрение.
• Разработчики подтверждают: форк нужен, потому что VSCode-расширения не позволяют глубоко интегрировать языковые сервисы, тулбары и кастомные UI.
• Некоторые считают продукт «ещё одним форком VSCode» и сомневаются в его нишевости между RStudio, VSCode, Spyder и PyCharm.
• Поддержка WSL пока отсутствует, а цены на RStudio Server выросли, что усиливает интерес к Positron в академической среде.
• Важнейший запрос — inline-вывод в Quarto; его уже рассматривают, и есть настройка для привычных хоткеев RStudio.

Chroma Cloud — серверлес-база поиска с открытым исходным кодом: быстро, дёшево, масштабируемо, надёжно.

Возможности

• Векторный, полнотекстовый и мета-поиск
• Форк коллекций
• Скоро: автоматическая синхронизация данных

Производительность

• Низкая латентность, высокий QPS
• Линейное масштабирование данных
• Хранение в объектном хранилище

DevEx

• Оплата по факту использования
• Веб-дашборд, CLI, локальная разработка
• Интеграция в CI/CD

Как начать

pip install chromadb
import chromadb
client = chromadb.CloudClient()
collection = client.get_or_create_collection("my_docs")
collection.add(
    documents=["Hello, world!", "Chroma is cool"],
    metadatas=[{"src": "demo"}, {"src": "demo"}],
    ids=["d1", "d2"]
)
print(collection.query(query_texts=["hello"], n_results=1))

Документация | Бесплатный старт

• Пользователи спрашивают, почему «open-source» просит деньги: ответ — сам Chroma под Apache 2.0 и бесплатен при самостоятельном развёртывании, а платная версия — это управляемый Chroma Cloud.
• Chroma поддерживает комбинированный поиск: фильтрацию по метаданным (category=X AND value>Y) + векторное сходство.
• Некоторые считают, что продукт и калькулятор цен слишком похожи на Turbopuffer; команда Chroma отвечает, что архитектуру обсуждали публично два года и уважают конкурентов.
• Для нетехнических пользователей Chroma решает задачу «R» в RAG: позволяет LLM «на лету» подтягивать нужные данные без дообучения модели.
• Стартапам предлагают помощь: совместное планирование, Slack-канал и персональная поддержка.
• Отличия от pgvector/Redis: собственные индексы (SPANN, SPFresh), шардирование, масштабирование, встроенный regex и trigram-поиск без нагрузки на основную БД.
• По сравнению с Qdrant Chroma позиционируется как «0 конфигураций и 0 операционной боли».

Программа должна оставаться валидной по мере набора.
Python-списковые включения плохи: пока вы не допишете for line in text.splitlines(), редактор не знает тип line, не может подсказать split() и даже не понимает, существует ли переменная.
В Rust text.lines().map(|line| line.split_whitespace()) строится слева-направо: сразу после line. доступны методы, и код всё время «жив».

Принцип progressive disclosure: сложность появляется ровно тогда, когда нужна. В C функции для FILE* начинаются на f; вводишь f и видишь сотни вариантов, не понимая, какой подходит. В идеале file. показал бы read, close и т. д. прямо во время набора.

Python и JS:

map(len, text.split())

— неясно, как называется длина (len, length, size?).

text.split(" ").map(w => w.length)

— length и map подсказываются сразу после точки.

С ростом логики читаемость падает:

len(list(filter(lambda line: all([abs(x) >= 1 and abs(x) <= 3 for x in line]) ...

• Обсуждение вращается вокруг идеи «слева-направо» синтаксиса: сначала контекст (объект, коллекция), потом действие, чтобы IDE могла мгновенно подсказывать.
• Критикуют Python- comprehensions и вложенные вызовы за «вправо-налево» порядок, мешающий автокомплиту и чтению.
• Многие хотят pipe-оператор (|>) или uniform call syntax, как в F#, Elixir, Nim, чтобы цепочки выглядели data |> filter(...) |> map(...).
• Противники считают, что язык не должен подстраиваться под автокомплит, а сложные цепочки лучше выносить в переменные или использовать методы.
• Примеры из SQL, JS/TS импортов, Rust for-loops и C# LINQ показывают ту же проблему: сначала надо указать, что ты хочешь получить, а потом — откуда.

Whispering — микросервис в репозитории epicenter-so/epicenter, каталог apps/whispering.
Предназначен для быстрого распознавания речи через OpenAI Whisper: принимает аудио-файл, возвращает текст.

Ключевые файлы

• main.py — FastAPI-endpoint /transcribe (POST, multipart/form-data).
• requirements.txt — fastapi, uvicorn, openai-whisper.
• Dockerfile — лёгкий образ на python:3.11-slim, порт 8000.

Запуск

docker build -t whispering .
docker run -p 8000:8000 whispering

или

pip install -r requirements.txt
uvicorn main:app --host 0.0.0.0 --port 8000

Использование

curl -F "file=@audio.mp3" http://localhost:8000/transcribe

Ответ: {"text": "распознанный текст"}.

• Пользователи делятся «костыльными», но рабочими схемами диктовки на Linux и обсуждают, как локально запускать Whisper/Parakeet без облаков.
• Epicenter продвигает идею «local-first»: plaintext + SQLite, прозрачные данные, открытый код, совместимые инструменты.
• Постоянно сравнивают альтернативы (VoiceInk, Superwhisper, Wispr Flow, Willow, whishper, Vibe) и жалуются на подписки, задержки, качество и отсутствие разметки динамиков.
• Разработчик Epicenter уже добавляет whisper.cpp и планирует Parakeet; просит помощи в PR для ускорения.

Reality Defender API
Два вызова кода — и ваша система получает признанные наградами модели для обнаружения дипфейков. Бесплатный тариф: 50 проверок аудио/изображений в месяц.

Почему Reality Defender API

• Простота — загрузка файла и получение результата.
• Гибкость — SDK на Python, TypeScript, Java, Go, Rust.
• Прозрачность — исходники открыты.
• Доступность — 50 сканов/мес без карты.

Тарифы

План	Цена	Включено
Free	$0	50 сканов/мес, аудио+изображение, 1 пользователь
Growth	от $399/мес	50+ сканов, аудио+изображение+видео, чат
Enterprise	по запросу	неограниченный объём, мультисид, видео+текст, стриминг, интеграции Zoom/Teams/Webex, расширение Chrome, персональная поддержка

Где применять

• Верификация личности (KYC, безопасный доступ)
• Мошенничество (имперсонация, соц-инженерия)
• Модерация контента
• Анализ СМИ и факт-чекинг
• Исследования и тесты

Поддерживаемые форматы

Аудио (до 100 МБ, 12 с – 5 мин): wav, flac, mp3, m4a, aac, ogg, opus; 8 языков.
Изображения (до 10 МБ): jpg, jpeg, png, gif, webp.
Видео (до 250 МБ): mp4, mov; аудио как выше.

Начать бесплатно | Документация SDK

• Участники сомневаются в надёжности «детекторов ИИ» и предсказывают бесконечную «кошку-мышь» между генераторами и детекторами.
• Предлагают альтернативу: криптографическую подпись контента, но признают, что добровольные стандарты легко обходятся.
• Основатели Reality Defender отвечают: ансамбль моделей выдаёт лишь вероятность 1-99 %, API закрыт, таргетинг по паттернам и лимит 50 бесплатных сканов мешают злоупотреблениям.
• Уже используется крупными банками и корпорациями для проверки подлинности медиа и документов.

CLI-инструменты часто зависят от платформы/версии, плохо документированы и ломаются при не-ASCII вводе. Агенты путаются в управлении состоянием (например, tmux-сессиями) и теряют контекст после мелкой ошибки. Каждый вызов ещё тормозит из-за предварительной проверки безопасности.

Композиция в CLI работает через bash: цепочки tmux send-keys, sleep, base64 и т.д. MCP сегодня так не умеет.

Выход — MCP-сервер с одним «убер-инструментом»: Python-интерпретатор, сохраняющий состояние между вызовами. Пример — pexpect-mcp: виртуальное окружение + pexpect, позволяющее скриптами управлять интерактивными CLI-программами. Вместо 30 отдельных MCP-функций достаточно одной, принимающей код.

• Участники спорят, нужен ли MCP (Model Context Protocol): кто-то считает его лишним слоем, другие — полезным способом дать LLM структурированные инструменты.
• Критика: MCP ограничивает агента набором команд, не решает безопасность, дублирует OpenAPI и заставляет LLM учиться новому формату вместо bash/API.
• Альтернативы: прямое обращение к HTTP/CLI/WebSocket (UTCP), YAML-описание тулов (hooks_mcp), eval в песочнице (runjs, Bubblewrap).
• Практические проблемы: при 100+ тулов агент путается; приходится писать кучу обвязок вместо «просто вызвать API».
• Общий вывод: MCP пока выглядит сыро, требует лишних усилий и не даёт очевидных преимуществ перед строками/bash/API.

llama-scan — локальный инструмент для транскрибирования PDF с помощью LLM.
Полностью работает на вашем ПК: данные не уходят в облако.
Поддерживает модели Llama 3.2 3B/1B, работает без GPU.

Возможности

• Конвертация PDF → Markdown
• Пакетная обработка папок
• Параллельные задачи
• Подсчёт токенов и стоимости
• Плагины для Obsidian и Zotero

Установка

pip install llamascan

Использование

CLI:

llamascan input.pdf --output out.md

Python:

from llamascan import transcribe
transcribe("file.pdf", model="llama3.2:3b")

Требования

• Python ≥ 3.9
• Ollama (для локальных моделей)

Лицензия

MIT

• Участники сравнивают LLM-OCR с классическими решениями: первые могут «галлюцинировать» и терять структуру, вторые точнее, но не понимают макет.
• Практики делятся пайплайнами: извлечь текст, снять скрин страницы, отправить всё в LLM с чётким промптом и структурированным выводом.
• Авторы жалуются на провисание процесса, пропуск символов и невозможность редактировать промпт под свои задачи (например, выделять только рукописные таблицы).
• Рекомендуют альтернативы: nanonets-ocr-s, Docling, Marker, Nougat, ocrmypdf, pgpdf, а также советуют бенчмарк OmniDocBench для объективной оценки.

• Markdown = лёгкая обёртка HTML, rST = промежуточное дерево документа.
• В Markdown картинка: ![alt](img.jpg) → прямое преобразование в <img>.
• В rST: .. image:: img.jpg :alt: alt → регистрируется обработчик, возвращает объект-узел, который потом рендерится нужным бэкендом.
• rST расширяем: добавил .. figure::, подключил обработчик — готово.
• Можно трансформировать дерево до вывода: перенос решений упражнений в конец книги, генерация ссылок, разные стили для HTML, PDF, EPUB.
• Пример: .. exercise:: Fizzbuzz и .. solution:: собираются в одном месте, но при сборке перемещаются в solutionlist, связываются ссылками, в EPUB открываются всплывающими сносками, в LaTeX — через answers.

• RST мощнее и расширяемее, но синтаксис вызывает отторжение и сложен для новичков.
• Markdown читается и пишется проще, поэтому стал де-факто стандартом, но не хватает возможностей для больших документов.
• MyST, Asciidoc, Djot и Typst предлагают компромисс между простотой и функциональностью, но пока уступают Markdown в распространённости инструментов.
• Парсеры RST доступны в основном на Python, а у Markdown — «каждый реализует свой диалект».
• Для книг и сложной документации RST + Sphinx выигрывают за счёт автогенерации HTML/PDF/EPUB, глоссариев и индексов.

Fallinorg – нажмите один раз и Mac станет чистым.
Файлы упорядочены, работает офлайн, данные не уходят в сеть.

Основное

• Локальный ИИ анализирует содержание, а не только имена.
• Полностью офлайн, без интернета.
• Поддержка .txt и PDF на английском.
• Свои папки – вы выбираете, куда складывать.
• Оптимизировано для Apple Silicon.

Покупка

Предпродажа: $9.49 единоразово
— неограниченное количество файлов
— выбор папок
— приватность
— поддержка по e-mail

Купить и скачать

FAQ

• Как анализирует? Sentence Transformers локально.
• Приватность? Всё на вашем Mac.
• Форматы? .txt и PDF, скоро больше.
• Папки? Вы решаете.
• Интернет? Не нужен.
• Intel? Пока нет; пишите на [email] для уведомления.
• Возврат? Пишите на [email] с причиной.
• Обновления? Все мелкие бесплатны; крупные – со скидкой для ранних покупателей.

Подпишитесь на рассылку, чтобы быть в курсе.

• Пользователи жалуются на 357-МБ Python-окружение и просят перейти на CoreML или ONNX Swift-bindings.
• Критика пресейл-цен и отсутствия пробной версии; создатель обещает прояснить условия и добавить roadmap.
• Запросы: поддержка epub/cbr/OCR-многоязычности, пользовательские категории, CLI-версия, Spotlight-импортер.
• Сейчас приложение работает только с PDF/txt, но расширение типов файлов и локализация в планах.
• Найдены опечатки и краши; создатель оперативно исправляет и просит репорты на GitHub.

LL3M — система, где несколько LLM пишут Python-код для Blender, создавая и редактируя 3D-модели по текстовым запросам. В отличие от прежних подходов, ограниченных примитивами, LL3M свободно формирует геометрию, компоновку и материалы. Код служит представлением объекта, что позволяет автоматическую и пользовательскую итеративную доработку.

Процесс

1. Создание — первичная модель.
2. Авто-улучшение — самокоррекция ошибок и упрощённой геометрии.
3. Пользовательская доработка — интерактивные правки по запросу.

Возможности

• Разнообразие форм: архитектура, инструменты, скейтборд и т.д.
• Стилизация: один запрос «в стиле стимпанк» меняет геометрию и материалы разных шляп.
• Материалы: процедурные шейдеры, редактируемые узлы.
• Последовательные правки: сохраняется идентичность объекта.
• Прозрачность: читаемый код с комментариями, понятные параметры в Blender.
• Повторное использование: общие паттерны кода переносятся между категориями объектов.
• Сцены: генерация иерархий объектов с корректными пространственными связями.

• Пользователи делятся опытом: meshy.ai превращает упрощённые 2D-изображения в 3D-модели, а Claude помогает писать Lua-скрипты для Aseprite и Python для FreeCAD/Blender.
• Ветераны Blender критикуют качество и высокий полигон-счёт, считая инструмент «игрушкой» или «обучающим» для новичков.
• Сторонники видят в этом будущее «solo-dev»: быстрый прототип, экономия времени и API-first подход в креативных пакетах.
• Поднимаются вопросы безопасности (несэндбоксированный Python), прав и монетизации опыта художников, а также необходимости понимания 3D-семантики для эффективных промптов.
• Общий консенсус: сейчас это «cute», но каждая новая итерация будет лучше, и генеративные модели всё ближе к «говорящим на языке геометрии».

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

c(I,K) += a(I,J) * b(J,K).          % умножение матриц
fib(N) := fib(N-1)+fib(N-2).       % числа Фибоначчи
phrase(X,I,K) max= phrase(Y,I,J)*phrase(Z,J,K)*rule(X,Y,Z).  % CKY-разбор

История: проект начат в 2004 для сокращения разрыва между математикой и кодом.

• Dyna 1.0 добавил произвольные полукольца к Datalog.
• Dyna 2.0 убрал ограничение на единое полукольцо, разрешил свободные переменные, ленивые и энергичные вычисления, наследование через dynabases.

Актуальные исследования

• Реализация через реляционную алгебру и перезапись термов.
• Использование обучения с подкреплением для выбора оптимального порядка вычислений.

Ключевые статьи

• PhD M. Francis-Landau «Declarative Programming Via Term Rewriting» (2024).

• Автор рад, что его PhD-исследование (язык Dyna3) попало на Hacker News.
• Dyna3 — это кложурная реализация Dyna, JIT-компилятор и «артефакт из будущего» по ощущениям читателей.
• Язык обобщает Datalog на произвольные полукольца, позволяя вероятностные выводы и динамическое программирование; схож со Scallop, но Scallop ориентирован на дифференцируемость и интеграцию с нейросетями.
• Пользователи спрашивают про «max=», «*» и связь с Prolog-грамматиками; Dyna использует переписывание термов с весами.
• Есть Python-, Clojure- и Java-API, но для продакшена нужны дополнительные годы разработки.

tinylisp — лисп-интерпретатор всего на 99 строк C.
Включает 21 примитив, сборщик мусора и REPL.
Доступны варианты с оптимизацией хвостовой рекурсии для ускорения и экономии памяти.

• Участники обсуждают крошечную реализацию Lisp, которую, по словам одного комментатора, могли писать для карманного компьютера Casio AI-1000 1989 г.
• Код раскритикован за «ужасный» стиль на C: злоупотребление double, нарушения strict aliasing и эндиан-зависимость.
• Предложены альтернативы: 100-строчный Lisp на Python, tinylisp, lispy.py Питера Норвига.
• Найдена синтаксическая ошибка в tinylisp (лишняя скобка) и отмечено отсутствие TCO, из-за чего Y-комбинатор не работает без доработки.

lue — терминальный ридер ePub с TTS.

• Основное: читает ePub, воспроизводит речью, работает в консоли.
• Управление: клавиши Vim-стиля, навигация по главам, закладки.
• Настройка: темы, голоса, скорость, горячие клавиши.
• Установка: cargo install lue или brew install lue.
• Системы: Linux, macOS, Windows.
• Лицензия: MIT.

• Пользователи тестируют новый инструмент lue для чтения/озвучки epub в терминале: TTS-часть ценят за «просто закинул и слушай», но чтение в моноширинном шрифте вызывает сомнения.
• Основная боль — внешние зависимости (espeak, antiword) и требование Python ≥ 3.10; автор уже пообещал поднять минимальную версию.
• Прогресс и состояние озвучки сохраняются в системных логах; серверный запуск позволит синхронизировать закладки.
• Сноски, колонтитулы и служебные символы вырезаются, чтобы не мешать TTS; возможно появится опция оставлять их для обычного чтения.
• Автор собрал адаптеры для Kitten TTS, Gemini и др., но пока не опубликовал их, размышляя о выделении отдельного репозитория.
• Вопросы о запуске из Termux/Android и безопасности кода пока без ответа; автор приветствует аудит и обратную связь.

• Imagen 4 и Imagen 4 Fast теперь доступны всем через Gemini API.
• Imagen 4 Fast генерирует изображения в 2 раза быстрее и дешевле, чем Imagen 3, без потери качества.
• Imagen 4 — флагманская модель: лучше текст, детали, стилизация; поддерживает 2K разрешение и редактирование (inpainting/outpainting).
• Цены:
  • Imagen 4 Fast: $0,03 за изображение 1024×1024.
  • Imagen 4: $0,05 за изображение 1024×1024.
• Как начать:

  from google import genai
  client = genai.Client(api_key="YOUR_API_KEY")
  response = client.models.generate_images(
      model="imagen-4-fast",
      prompt="A cat wearing a space helmet on Mars"
  )
  

• Доступно в 180+ странах через Google AI Studio и Gemini API.

• Пользователи жалуются, что Imagen 4/Ultra игнорирует детальные промпты: четырёхпанельный комикс не соблюдает ни стиль, ни содержание.
• Сравнения показывают, что «Ultra» не лучше обычной версии, а иногда даже хуже; OpenAI и Copilot дают точнее.
• Документация отсутствует, примеры устарели, а вывод часто «мультяшный» вместо фотореалистичного.
• Сообщество шутит над ошибками, опечатками Google и общим качеством «AI-slop».

Qodo Command набрал 71,2 % на SWE-bench Verified — стандартном бенчмарке для оценки способности агентов решать реальные задачи из GitHub.

• SWE-bench Verified включает 500 задач из 12 популярных репозиториев (Django, scikit-learn, sympy и др.).
• Каждая задача: описание бага/фичи + тест, который должен проходить после исправления.
• Оценивается только успешность прохождения тестов; стиль и качество кода не учитываются.

Результаты

• 71,2 % — новый рекорд среди публичных решений.
• +18,2 п.п. от предыдущего лидера (CodeStory Aide).
• +31,2 п.п. от первого релиза SWE-bench (2023).

Ключевые инсайты

• Контекст важнее модели: использование 128k-токенного окна и RAG-поиска по 500+ файлам дало +12 %.
• Итерации решают: 3–5 попыток сборки/тестов повышают успех на 8 %.
• Маленькие PR легче: задачи <30 строк кода решаются в 84 % случаев, >200 — лишь 38 %.

Что дальше

• Публикация детального тех-отчёта и открытого датасета.
• Расширение до 1 000 задач и добавление новых языков (Go, Rust).

• Qodo показал 71,2 % на SWE-bench-verified — 5-е место, всего на 1 % уступая официальному Claude Sonnet 4.
• Участники сомневаются в честности результатов и просят независимую платформу с peer-review.
• Поднимаются вопросы о стоимости, эффективности, размере модели и специфике подготовки именно под тест.
• Обсуждают, что сам бенчмарк «закрыт» для Python-ошибок и не отражает реальную разработку.
• Некоторые уже отказались от Qodo в пользу BugBot и сомневаются в жизнеспособности «обёрток» над LLM.

GitHub репозиторий danterolle/tilf

Публичный репозиторий, форков нет.

Навигация

• Продукты: Copilot, Spark, Models, Advanced Security, Actions, Codespaces, Issues, Code Review, Discussions, Code Search.
• Решения: по размеру компании, сценариям (DevSecOps, CI/CD) и отраслям (здравоохранение, финансы и др.).
• Ресурсы: статьи по AI, DevOps, безопасности; вебинары, электронные книги, истории клиентов.
• Open Source: Sponsors, ReadME Project, темы, тренды, подборки.
• Enterprise: платформа, Advanced Security, Copilot для бизнеса, премиум-поддержка.
• Цены: github.com/pricing.

Поиск
Поддерживает фильтры и сохранённые запросы. Требуется вход для настройки уведомлений и форков.

• Пользователи делятся инструментами для создания пиксель-арта (unfake.js, PixelLab, mtPaint, Aseprite, LibreSprite).
• Автор Tilf подтвердил: проект ручной, зависит только от PySide6, собран PyInstaller’ом, иконки и логотип нарисованы вручную/частично с AI.
• Название Tilf = «Tiny Elf» («крошечный эльф»), выбрано за простоту и образ.
• Предложены улучшения: сдвиг строк/столбцов, добавить GitHub-теги, нарисовать логотип пиксель-артом.
• Сообщество обсуждает «стыд за AI-код» и отмечает приятную «домашнюю» атмосферу проекта.

• Добавлена поддержка моделей Mistral-Small-3.1-24B-Instruct-2503 и Mistral-Small-24B-Instruct-2501
• Улучшена работа с Mamba-2 и Sliding Window Attention
• Новые правила конвертации: convert-hf-to-gguf.py теперь корректно обрабатывает sliding_window, mamba2, attention_bias, tie_word_embeddings
• Обновлён llama_model_loader и llama_model: добавлены поля mamba2 и sliding_window, упрощена логика KV-cache
• Поддержка mamba2 в llama_context и llama_decode
• Удалены устаревшие llama_model и llama_vocab
• Добавлены тесты test-mistral.py и test-mistral-vision.py

• Mistral предлагает mistral-common как официальный токенизатор, но пока только через Python-библиотеку и временный REST-обвязанный FastAPI.
• Сообщество жалуется: «cpp-бинарь, зависящий от Python-сервера — временное и грустное решение», ждут нативный C++ порт.
• Пользователи расстроены, что Mistral, выпуская веса, не сразу поддерживает llama.cpp, на котором держится большинство «домашних» запусков.
• Некоторые замечают, что llama.cpp и так тянет Python для шаблонов, но это не отменяет желания увидеть полноценную C++ реализацию.
• Сторонники Mistral отвечают: компания маленькая, пока не ясно, какие именно инференс-фреймворки поддерживать, зато открыли собственный mistral-inference.

Переписал Ghuloum-туториал на Python (~300 строк). Убрал читалку S-выражений и бинарный код — теперь текстовая ассемблерная печать.

Lambda-lifting требует:

• знать связанные переменные;
• собирать свободные переменные лямбд;
• накапливать создаваемые code-объекты.

Связывают let и lambda; для них обновляем окружение.

Lifter

class LambdaConverter:
    def __init__(self):
        self.labels = {}

    def convert(self, expr, bound, free):
        match expr:
            case int() | Char() | bool():
                return expr
            case str() if expr in bound or expr in BUILTINS:
                return expr
            case str():
                free.add(expr)
                return expr
            case ["if", t, c, a]:
                return ["if",
                        self.convert(t, bound, free),
                        self.convert(c, bound, free),
                        self.convert(a, bound, free)]

lift_lambdas запускает обход и возвращает (labels …).

Lambda

Лямбда:

• связывает параметры;
• выделяет код;
• захватывает внешнее окружение.

Пример:

(lambda () x)  ; x свободна

превращается в

(labels ((f0 (code () (x) x)))
  (closure f0 x))

Даже если x связан снаружи, внутри лямбды он считается свободным.

• Участники рекомендуют три современные книги по компиляторам, вдохновлённые статьёй Ghuloum: «Writing a C Compiler» (Sandler), «Essentials of Compilation» на Racket и Python (Siek).
• Обсуждали «lambda lifting»: преобразование, выносящее замыкания наверх, уменьшая их размер вплоть до полного исчезновения.
• Уточнили, что «lambda lifting» в статье связан с разделом 3.11 о сложных константах в Scheme.
• Разбирали, почему современный ИИ использует Python, а не Lisp: удобство как «клея» для C++/CUDA, упадок доли рынка Lisp и смена парадигмы ИИ.

POML — язык разметки Prompt Orchestration Markup от Microsoft.
Проект в открытом доступе на GitHub: microsoft/poml.

• Назначение: структурировать, версионировать и переиспользовать промпты для LLM.
• Формат: YAML-подобный, читаемый человеком и парсером.
• Возможности:
  – параметризованные шаблоны,
  – условные ветвления,
  – импорт фрагментов,
  – метаданные (автор, версия, модель).
• CLI: poml build → компиляция в чистый текст, poml test → прогон с примерами.
• CI/CD: экшены GitHub для валидации и деплоя промптов.
• Интеграции: Python SDK, VS Code-расширение, экспорт в OpenAI, Azure, Bedrock.

• POML — это XML-подобный DSL от Microsoft Research для «view-слоя» промптов, но выглядит как «JSX, только хуже» и заставляет писать код в строках.
• Участники сравнивают его с YAML-промптами GitHub, BAML (TypeScript-подобные схемы), Jinja и обычным XML, споря о необходимости новой библиотеки.
• Критика: один контрибьютор при $3T-спонсоре, нет SDK для .NET/C#, лишний tooling, «IP squatting», циклы в XML выглядят как костыль.
• Ирония: из-за потребности в точности неформальные LLM-промпты всё структурнее, как юридические документы.

abogen — консольный инструмент, превращающий EPUB, PDF и обычный текст в аудиокниги с синхронными субтитрами.

Возможности

• Форматы: EPUB, PDF, TXT.
• TTS-движки: Coqui TTS, OpenAI TTS, Edge TTS, Google TTS.
• Субтитры: SRT/VTT, привязанные к словам.
• Языки: 40+, включая русский.
• CLI: abogen book.epub --voice en-US-AriaNeural --output book.m4b.

Установка

pip install abogen

Использование

abogen mybook.pdf --voice ru-RU-SvetlanaNeural --format m4b

Ссылки

• GitHub
• PyPI

• Пользователи обсуждают Abogen — GUI-обёртку над Kokoro TTS для генерации аудиокниг из текста.
• Качество голоса признаётся «ровным», но без эмоций и актёрской игры; для художественных книг это критично.
• Отмечены проблемы: долгие предложения обрезаются, «Mr.» читается с лишней паузой, видео-демо без звука в Firefox.
• Кто-то хочет API и автоматический пайплайн Calibre-Web → Abogen → Audiobookshelf, другие — формат DAISY и «голос Моргана Фримена».
• Итог: инструмент годен для личного использования и доступности, но пока не дотягивает до коммерческих аудиокниг.

Debian 13 «trixie» вышел 9 августа 2025 года после 2 лет разработки.
Поддержка — 5 лет (Security + LTS).

Десктопы: GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1, Xfce 4.20.
Пакетов: 69 830 (+14 100 новых, –8 840 устаревших, 44 326 обновлённых).
Размер: 403 ГБ, 1,46 млрд строк кода.
Ядро: 6.12 LTS; первый релиз с официальной поддержкой riscv64.
Архитектуры: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x.
i386 больше не поддерживается; armel последний релиз.

Ключевые обновления: Apache 2.4.64, Bash 5.2.37, BIND 9.20, GCC 14.2, LibreOffice 25.2, MariaDB 11.8, Nginx 1.26, OpenJDK 21, PHP 8.4, PostgreSQL 17, Python 3.13, Rust 1.85, systemd 257 и др.

Облако: образы для EC2, Azure, OpenStack, PlainVM, NoCloud с cloud-init и оптимизированным загрузчиком.
Live-образы: amd64/arm64, GNOME/KDE и др.; установка через Calamares или стандартный установщик.

• Debian 13 «Trixie» вышла: 63 % пакетов обновлены, поддержка 7 архитектур, включая RISC-V.
• i386 теперь только как «amd32»-совместимый, официального ядра/инсталлятора нет.
• Появился новый формат APT-репозиториев debian.sources, старый sources.list пока работает.
• 95 % пакетов достигают bit-for-bit воспроизводимости на amd64/arm64/riscv64.
• /tmp теперь tmpfs по умолчанию (до 50 % ОЗУ), но можно вернуть старое поведение.
• Пользователи хвалят стабильность, скорость обновления «stable→stable» и отсутствие snap.

LLM-разработка: краткий итог

• Мифы: LLM не делают код продакшн-готовым, требуют понимания задачи и хорошо структурированных кодовых баз. Использование LLM снижает навыки чтения документации и глубокого мышления.
• Агенты — это просто цикл «LLM → вызов локального API → ответ → LLM снова». Инструменты: навигация, редактирование, shell, поиск, MCP-серверы.
• Проблемы продуктов
  • Нестабильность: модели и цены меняются еженедельно.
  • Нет детерминизма, приходится постоянно обновлять промпты и MCP.
• Тесты
  • Python, TypeScript, Rust, Flutter, сложные рефакторинги — справляются.
  • Не справились: Token Field во Flutter (редкий компонент, сложное управление состоянием). Claude Opus 4.1 и GPT-5 провалили задачу.

Продукты

• GitHub Copilot

  • Плюсы: быстрое автодополнение, стабильность, низкая цена.
  • Минусы: слабые «агенты», нет контекста всего проекта.

• Claude Code Pro

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

• Gemini CLI / Jules

  • Плюсы: бесплатный CLI, быстрый.
  • Минусы: слабые модели, ограниченные возможности.

• Kiro, Cursor, Windsurf

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

Когда LLM полезны

• Лучшие языки: Python, TypeScript/JavaScript, Go.
• Лучшие задачи:
  • Репетитивный код, тесты, миграции.
  • Документация, примеры, объяснение legacy.
• Плохо:
  • Редкие фреймворки, сложные UI, архитектурные решения.
  • Надёжность и безопасность.

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

• Многие спорят с тезисом «использовать LLM в коде тривиально»: на практике нужны месяцы, чтобы понять, что делегировать, как формировать промпты и управлять контекстом.
• Кто-то сравнивает LLM с «однорукими бандитами»: результат часто случаен, а «навыки» сводятся к удаче и базовому гуглению.
• Другие делятся успешным опытом: при жёсткой архитектуре, тестах и узких промптах Claude Code и аналоги дают 9/10 полезных патчей.
• Утверждение, что LLM «заставляют» выбирать мейнстек, опровергают разработчики на Clojure, D и других нишевых языках.
• Общий вывод: LLM — мощный инструмент, но требует экспериментов, критического ревью и понимания своих ограничений; без этого он быстро превращается в источник технического долга.

1984: словарь в 256 КБ

Представьте: вам поручили написать спеллчекер для MS-DOS-текстового редактора. У части пользователей всего 256 КБ ОЗУ — и туда должны поместиться редактор, сам документ, ОС и ещё словарь. Сегодня /usr/share/dict/words весит 2,5 МБ и содержит 235 000 слов; тогда это был нереальный объём.

Сжатие трие, вырезание редких слов, кастомная БД на гибком диске 360 КБ — всё это требовало месяцев инженерной работы и гениальных структур данных.

Сейчас

Загрузить словарь в хеш-таблицу — 3–5 строк на Perl или Python; поиск слова — встроенная операция. Всё.

• Пользователи жалуются, что встроенный спелл-чекер iPhone (и Android) часто хуже человеческого глаза и LLM: «No Guesses Found» при очевидных ошибках.
• Причины: жёсткие ограничения по скорости и памяти, отсутствие контекста, излишняя буквальность алгоритмов.
• Многие отказались от встроенных средств и ищут слова в Google или используют LLM.
• Участники вспоминают, как в 80-е спелл-чекер был прорывом, но требовал переключения дискет и выдавал лишь список ошибок без подсказок.
• Сегодня задача «проверить орфографию» тривиальна, а вот «предложить правильное» по-прежнему требует сложной инженерии.

• Выбор хранилища метаданных рабочих процессов оказался ключевым. Нужно было простое: чекпойнт состояния и восстановление после сбоя. Postgres выбрали за технические возможности, а не только за популярность и 40-летнюю проверку временем.

• Масштабируемые очереди
  Классическая таблица-очередь страдает от конкуренции: все воркеры пытаются взять одни и те же задачи. Postgres решает это через FOR UPDATE SKIP LOCKED: строки блокируются и пропускаются, если уже захвачены. Воркеры без конфликтов берут следующие N записей, позволяя обрабатывать десятки тысяч задач в секунду.

• Наблюдаемость
  Каждый шаг сохраняется, поэтому можно строить дашборды и фильтры. SQL позволяет писать сложные запросы напрямую; индексы по created_at, executor_id, status ускоряют выборки из миллионов записей без лишних затрат.

• Exactly-once для шагов с БД
  Обычно гарантируется «по крайней мере один раз», но если шаг меняет данные в той же транзакции, что и чекпойнт, Postgres обеспечит, что изменения зафиксируются ровно один раз даже после перезапуска.

• Пользователи хвалят DBOS за простоту миграции с graphile-worker и отсутствие необходимости менять инфраструктуру.
• Сравнения с Temporal, Azure Durable Functions, Inngest, Restate и Cloudflare: DBOS выглядит проще и легче, но Temporal/Cloudflare критикуют за сложность самостоятельного хостинга и высокую цену.
• Некоторые жалуются, что «сервер» DBOS (Conductor) не open-source, что ограничивает самостоятельное развёртывание.
• Планы по добавлению Java, C#, Go и поддержке сообщества уже анонсированы; Python и TypeScript уже поддерживаются.
• Отмечена возможность комбинировать DBOS с Dagster/Oban/pgflow для более сложной оркестрации.

• Несколько лет назад мне выпал шанс выбрать async‑first, типизированный Python‑фреймворк для веба. Я взял Litestar — без хайпа и ракет в твитах — и не пожалел: уже около 18 месяцев все мои новые рабочие проекты на нём.

• Даже если вы пишете асинхронные веб‑приложения на Python, вы могли пройти мимо Litestar. Хочу это исправить.

• Вкус демо: простой файл

  from litestar import Litestar, get
  
  @get("/greet")
  async def greet(name: str) -> str:
      return f"Hi, {name}!"
  
  app = Litestar([greet])
  

  Запускаете через litestar run или любой ASGI‑сервер. /greet?name=Bob вернёт «Hi, Bob!». Без name — HTTP 400: параметр обязателен. Да, похоже на FastAPI и на знакомые по Spring/ASP.NET MVC подходы с аннотациями — и FastAPI тоже так умеет. Но у Litestar есть свои сильные стороны.

• Про название: раньше проект назывался Starlite, потому что изначально строился на Starlette (как и FastAPI). Позже зависимость убрали, а чтобы не путать со Starlette, в релизе 2.0 (2023) переименовали в Litestar.

• Масштабирование кода, а не трафика:

  • Django плохо «масштабируется вниз»: «правильный» старт быстро разрастается в десяток файлов и папок. Однофайловые трюки работают, но против шерсти.
  • Микрофреймворки — наоборот: стартуют в одном файле, но по мере роста кода расползаются и начинают мешать.
  • В FastAPI маршруты обычно вешаются декораторами на объект приложения. Это удобно в одном файле, но при разбиении на модули ведёт к циклическим импортам. Решение — «вторичные» реестры маршрутов (APIRouter, blueprint): нужны, потому что декораторы привязаны к app. Litestar же позволяет описывать обработчики отдельно и передавать их приложению списком, что естественно масштабируется от одного файла к структуре проекта без костылей.

• Обсуждение сравнивает FastAPI, Litestar, Starlette и Django для построения бекендов: многие отмечают, что FastAPI удобен для простых сервисов, но усложняется в больших кодовых базах, тогда как Litestar воспринимается более продуманным и быстрым для сложных API.
• Несколько участников хвалят Litestar: высокая скорость, асинхронность, first-class msgspec, контроллеры для вложенных роутов, кеширование, плагины (в т.ч. для HTMX), и развивающийся Advanced Alchemy; отмечают, что у него больше одного мейнтейнера.
• Часть разработчиков предпочитает Starlette как легковесную основу без «всей кухни», а Django ценят за ORM; обсуждают плюсы/минусы SQLAlchemy и альтернативы (peewee), а также идею разделять модели API и БД с самого начала.
• Критика FastAPI касается структуры кода, управления зависимостями и разрыва между туториалами и реальными практиками; при этом приводят ссылки на репозитории-референсы, где показано, как масштабировать FastAPI.
• Запросы и сомнения: как обрабатывать ошибки при стриминге, как деплоить (NGINX Unit упоминался как «капризный»), и нужен ли референс-проект Litestar; приводят litestar-fullstack как пример.
• В целом тон дискуссии: многие либо мигрируют с FastAPI на Litestar, либо довольны Starlette; документацию нового поколения фреймворков часто критикуют за недостаток строгого API-референса и переизбыток туториалов.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

Я люблю делиться: пишу блог, веду цифровой сад заметок и выкладываю почти весь код на GitHub. И обожаю читать чужие dotfiles, учиться у них.

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.

• Самая быстрая и надежная 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), но общий тон — трезвый: дисциплина риск-менеджмента важнее «волшебных» моделей, а охота за стратегиями — глубокая и дорогостоящая нора.

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

• State-of-the-art модель TTS до 25 МБ 😻
• Пропустить к содержимому
• Навигация, вход, настройки внешнего вида
• Продукты: Copilot, Spark, Models, Advanced Security, Actions, Codespaces, Issues, Code Review, Discussions, Code Search
• Исследовать: Почему GitHub, все функции, документация, навыки, блог
• Решения по размеру компании: Enterprise, для команд, стартапов, НКО
• По задачам: DevSecOps, DevOps, CI/CD и др.
• По индустриям: здравоохранение, финансы, производство, гос сектор
• Ресурсы: темы (ИИ, DevOps, безопасность, разработка), курсы, события, книги, истории клиентов, партнёры, аналитика
• Open Source: Sponsors, ReadME Project
• Репозитории: Темы, Тренды, Коллекции
• Enterprise: платформа, допы — Advanced Security, Copilot for business, поддержка
• Цены
• Поиск кода и репозиториев, советы по синтаксису
• Обратная связь (с email), отправка/отмена
• Сохранённые поиски: создание/управление, документация по синтаксису
• Вход/регистрация
• Сообщения о перезагрузке сессии и переключении аккаунтов
• KittenML/KittenTTS (публичный), уведомления, форки

• KittenTTS (25 МБ, Apache-2.0) генерирует речь оффлайн на CPU, но звучит механически и путает цифры.
• На i9-14900HX 225 символов синтезируются за 5,5× реального времени, но латентность ~315 мс.
• Установка требует кучи зависимостей, поэтому «25 МБ» быстро превращаются в гигабайты.
• Для качественной речи пользователи рекомендуют F5-TTS, Fish-Speech или Piper-TTS; для STT — Whisper.
• Сообщество просит ONNX-порт, обучение на других языках и открытые данные.

marimo — новый open-source Python-ноутбук, в котором программа представлена графом потока данных. Это снимает главные боли Jupyter: скрытое состояние, невоспроизводимость, невозможность повторного использования и сложную поддержку.

Почему старый формат не подходит

• Воспроизводимость. Исследования 2019–2020 гг. показали: только 4–24 % ноутбуков на GitHub можно перезапустить без ошибок и получить те же результаты. Причина — скрытое состояние: удаление или переупорядочивание ячеек ломает выводы.
• Интерактивность. В Jupyter интерактивен процесс, но не сами данные: выделение точек на графике не возвращает датафрейм.
• Поддержка и переиспользование. Файл .ipynb — это JSON-блоб, не валидный Python-код; сложно версионировать в Git и переиспользовать как модуль или пайплайн.

Как marimo решает задачу

• Каждый ноутбук — корректный Python-скрипт и модуль.
• Граф зависимостей ячеек строится статически; изменение одной ячейки автоматически перезапускает только зависимые.
• Реактивность: обновление переменной мгновенно отражается во всех графиках и виджетах.
• Один файл можно экспортировать как приложение или запускать без ядра Jupyter.

• Пользователи хвалят marimo за реактивное исполнение, «песочницу» uv и лёгкий обмен с коллегами.
• Сторонники Jupyter считают, что «restart kernel & run all» решает проблему воспроизводимости, но критики отвечают: это требует дисциплины и не работает при тяжёлых вычислениях.
• Некоторые видят в ноутбуках лишь инструмент разведки и предлагают после исследования переносить код в обычные .py-файлы.
• Участники сходятся, что метаданные зависимостей и чистые DAG-подобные модели вычислений могли бы улучшить ситуацию.

Открытые модели OpenAI

Продвинутые модели с открытыми весами для любого кейса и запуска где угодно.

Ссылки:

• Загрузить на Hugging Face
• Исходники на GitHub
• Попробовать демо

Модели:

• gpt-oss-120b — крупная модель для дата-центров и мощных ПК/ноутбуков.
• gpt-oss-20b — средняя модель, работает на большинстве ПК/ноутбуков.

Преимущества:

• Разрешительная лицензия: Apache 2.0 — свободная разработка, без копилефта и патентных рисков; подходит для экспериментов, кастомизации и коммерческого использования.
• Для агентных задач: сильное следование инструкциям и работа с инструментами в ходе рассуждений (веб-поиск, запуск Python-кода).
• Глубокая настраиваемость: выбор уровня «усилия рассуждений» (низкий/средний/высокий) и полно-параметрический финтюнинг под ваш кейс.
• Полная «цепочка рассуждений»: доступна для удобной отладки и повышения доверия к ответам.

Интерактивное демо:

• Простой playground для запуска обеих моделей в браузере.

• Обсуждение посвящено выходу открытых моделей OpenAI gpt-oss (20B и 120B), которые по бенчмаркам близки к o3/o4-mini и местами обгоняют открытые лидеры; многие отмечают, что 20B уже реально запускается локально на Mac/мобильных устройствах.
• Пользователи делятся первыми впечатлениями и ссылками на обзоры/модель-карты, отмечая конкурентную производительность, совместимый токенайзер и адекватное лицензирование; есть поддержка в llama.cpp, Ollama, LM Studio, Harmony формат ответов и растущая роль Rust в инструментах OpenAI.
• Скорости инференса сильно варьируются: от очень быстрых облачных провайдеров (Cerebras/Groq на OpenRouter) до заметных задержек локально при больших контекстах; производительность зависит от GPU/платформы и параметров квантования.
• Отмечают стратегический сдвиг OpenAI к модели Meta: открытые веса как средство захвата экосистемы и снижения порога входа; звучат предположения, что релиз предвосхищает скорый анонс ещё более сильной закрытой модели.
• Сообщество обсуждает экономику: гибридные пайплайны (локально — простые задачи, в облако — сложные), возможность заменять платные подписки локальным запуском, и общий тренд в пользу OSS при минимальной разнице в качестве.
• Есть критика: у 120B встречаются галлюцинации на фактах, часть пользователей недовольна агрессивной безопасностью/отказами, отсутствием оптимизаций под RTX 50, а также неполной мультимодальностью.
• В целом настроение позитивное: многие благодарят за «настоящий» открытый релиз с сопутствующими инструментами и ожидают независимых бенчмарков, которые могут закрепить лидерство gpt-oss среди текстовых открытых моделей.

I was fresh at university, around 2001, and our mathematics professor introduced us to Python with NumPy/SciPy as an alternative to the commercial math tools. There aren't many events that changed my career as much as that. Being exposed only to compiled languages before that, it