Cloudflare и VoidZero совместно с Максом Швенком из Owner.com работают над tsrs — портом компилятора TypeScript на Rust, который развивается в составе инструментальной цепочки Oxc. Это не форк: команда TypeScript сохраняет полный контроль над языком, а порт обязан строго следовать её решениям, иначе со временем станет несовместимым. Ранние замеры обещают до 8 раз большей скорости и примерно на 70% меньше памяти по сравнению с TypeScript 7.0 при том же числе обработчиков проверки типов. При этом TypeScript 7.1 beta уже до 2.5 раз быстрее 7.0, и часть оптимизаций пришла из tsrs.

Попробовать экспериментальную версию можно через npm install tsrs и npx tsrs. Rust выбран не только ради скорости: важна и сборка в WebAssembly, что упрощает запуск полноценной среды разработки прямо в браузере. По умолчанию tsrs использует адаптивную конфигурацию, зависящую от типа машины: она потребляет больше памяти, но работает ещё быстрее. Авторы подчёркивают, что раньше масштабные порты почти не удавались, а теперь передовые ИИ-модели способны выполнять их за считанные дни.

Процесс сопровождается автоматикой: агенты ежедневно проверяют изменения, собирают диффы и заводят задачи, а ночью прогоняют тесты Next.js против Vinext, выявляя расхождения. Тот же подход применят к TypeScript, стараясь не вносить отличий в поведение и возвращая улучшения производительности в кодовую базу TypeScript на Go. Пока есть расхождения, например порядок вывода диагностик, но к стабильному релизу их сведут к минимуму. В планах — более глубокая интеграция tsrs в стек Cloudflare, в том числе для типозависимых правил линтера в Oxlint.

tsrs демонстрирует до 8-кратный рост скорости и снижение потребления памяти на ~70%. Эти показатели достигнуты не только за счет Rust, но и благодаря алгоритмическим оптимизациям, которые планируют перенести в TypeScript 7.1. Основным драйвером порта стала необходимость легкого компилятора для WASM-песочницы, где Rust предпочтительнее тяжелого Go-runtime. При этом арена-модель памяти в tsrs вызывает опасения, так как скрывает unsafe-код и может быть небезопасной. Также отмечается, что AI-генерация порта ускоряет разработку, но требует тщательного ревью из-за риска архитектурных ошибок. tsrs хорошо масштабируется при многопоточном запуске и поддерживает инкрементные проверки, хотя bun остается эффективнее по общим метрикам.

Pele — это новый рендерер диаграмм Mermaid в SVG, который работает без зависимостей и заметно быстрее и легче оригинала. Он поддерживает все типы диаграмм, встроенные в Mermaid 12.1.0, а тема оформления задаётся через CSS-переменные: цвета и шрифты меняются без повторного рендеринга. Достаточно передать синтаксис Mermaid в функцию render() и вставить полученный SVG в страницу.

Ключевые цифры впечатляют: сжатый размер сборки — 230 КБ против 1,6 МБ у Mermaid.js (в 6 раз меньше), время рендеринга — 0,05–0,3 мс против 6–82 мс (до 500 раз быстрее), а прямых зависимостей нет вовсе против 23 у Mermaid. На маленьких экранах Pele адаптирует компоновку, тогда как Mermaid просто масштабирует диаграмму.

Проект открыт, разработан для Obsidian и назван в честь богини вулканов и огня Пеле. Установка — через npm install pele.

Обсуждение подтверждает, что у оригинального Mermaid есть серьёзные проблемы с автоматическим расположением элементов, а Pele предлагает открытый и более гибкий рендерер, однако пользователи отмечают недостатки в темной теме, возможные баги в playground и делятся советами по альтернативным библиотекам и интеграции с CI/CD.

• Многие комментаторы (lukeify, tptacek, invokestatic) отмечают, что автоматический layout в Mermaid часто получается запутанным и топологически плохим, что делает его непригодным для сложных диаграмм.

• Совет: invokestatic советует использовать Python‐библиотеку mermaidx для генерации диаграмм в CI/CD, но предупреждает, что её layout может быть непредсказуемым и иногда приходится экспортировать PNG.

• Imustaskforhelp и blktiger подтвердили, что Pele является открытым проектом, размещённым в репозитории https://github.com/obsidianmd/pele, и предложили добавить видимую иконку GitHub для удобства.

• Совет: kepano объяснил, что Pele рендерит SVG, следуя только синтаксису Mermaid, а не его алгоритму расположения, и предоставляет режим сравнения, что решает многие жалобы на плохой layout.

• shellerik указал, что текущие примеры Pele недостаточно адаптированы к тёмной теме, что может затруднять использование в темных редакторах.

• Совет: Ancapistani отметил, что в Pele подграфы сохраняют своё направление даже при соединении с внешними узлами, что является весомым аргументом для перехода с Mermaid, несмотря на возможную разницу в скорости.

• kinduff сообщил о поломке предпросмотра Mermaid в playground Pele, а kepano запросил детали, указывая на необходимость исправления.

• Совет: dbg31415 подчеркнул, что такие инструменты позволяют интегрировать генерацию диаграмм в AI‐ассистенты (например, Claude) и сохранять их в markdown, что упрощает контроль версий.

С версии 0.157.0 CLI-инструмент Codex при простом запуске интерактивной сессии стал автоматически поднимать постоянный фоновый демон (codex app-server --managed-daemon). Он работает без TTY, переживает закрытие всех окон (переподчиняется процессу 1) и завершается только командой остановки или перезагрузкой. Автор предлагает сделать daemon_auto_start опциональным (по умолчанию false) либо хотя бы один раз спрашивать согласие.

Демон копирует весь платформенный пакет (~374 МБ: codex, codex-code-mode-host, встроенные bwrap/zsh/rg) в ~/.codex/packages/app-server-daemon/releases/<версия>/ и запускается из копии, из-за чего версия бэкенда расходится с установленной через пакетный менеджер. Отдельный самообновляющийся процесс (pid-update-loop) проверяет обновления через 5 минут, затем ежечасно, скачивает новые релизы и перезапускает бэкенд, что может убивать активные сессии. Демон также «закрепляет» окружение первой сессии: например, переменные HTTPS_PROXY остаются от того запуска, который его стартовал, независимо от параметров последующих сессий.

Для CLI ожидаемо, чтобы бэкенд жил и умирал вместе с окном, запускал установленный бинарник и не обновлялся сам. Если поведение оставят по умолчанию, автор просит завершать демон при отключении последнего клиента и не копировать/самообновляться при установке через npm/brew/pacman. Обнаружен и баг: daemon stop останавливает app-server, но оставляет pid-update-loop живым. Обходной путь — отключить функцию, остановить демон, вручную убить процесс обновления и удалить каталог пакета.

Автозапуск демона Codex CLI вызывает проблемы: баги, переполнение диска (до 12 ГБ в ~/.codex), нарушение прав доступа (например, .git становится доступен только для чтения) и блокировку выполнения целей. Демон работает независимо от TTY и не наследует переменные окружения шелла, что ломает автоматизацию. Некоторые пользователи считают такой скрытый процесс небезопасным и сравнивают его с «бекдором». Способы решения: 1. Отключить автозапуск в ~/.codex/config.toml: `[features] daemon_auto_start = false`. 2. Использовать флаг `--no-daemon`. 3. Полностью заблокировать демон, заменив pid- и lock-файлы ссылками на /dev/null с командой `chattr +i`. 4. Перейти на минимальные инструменты (hax) или изолировать Codex в Docker-контейнере с фиксированными версиями. Мнения об автообновлениях разделились: одни считают их стандартной практикой, другие — опасными и враждебными к пользователю.

Разработчики часто избегают использования нативных возможностей браузера, несмотря на их производительность и надёжность, из-за исторической нестабильности веб-платформы. Долгое время браузеры отставали от потребностей разработчиков, и библиотеки вроде jQuery заполняли критические пробелы, пока стандарты не догоняли. Даже после появления evergreen-браузеров привычка искать решения в npm осталась сильной: разработчики привыкли к знакомым интерфейсам фреймворков и библиотек, где документация понятна, примеры наглядны, а API обёрнут в удобную оболочку. Нативные API, хотя и мощные, часто кажутся «неуклюжими» или плохо документированными по сравнению с привлекательными страницами сторонних пакетов, такими как Dragula, чей сайт выглядит гораздо более приглашающе, чем сухая страница MDN.

Кроме того, существует разделение труда в экосистеме: опытные разработчики готовы использовать низкоуровневые DOM-операции в библиотеках, если они скрыты за привычными абстракциями вроде JSX или хуков React. Это позволяет новичкам работать с высокоуровневыми primitives, не погружаясь в сложности платформы. Однако с ростом ИИ-ассистентов в коде ситуация может измениться: в оптимистичном сценарии агенты будут выбирать платформенные API как более эффективные и проверенные решения, снижая необходимость в избыточном пользовательском коде. В пессимистичном же случае ИИ будет генерировать дублирующий, неидиоматичный код, усиливая фрагментацию и переусложнение, поскольку разработчики могут не тратить время на проверку альтернатив. В любом случае, напряжение между удобством экосистемы и чистотой платформы останется актуальным.

Разработчики избегают нативных возможностей браузера из-за исторической нестабильности, неполноценных API (Web Components, <dialog>, <datalist>), давления дизайнеров и продуктовых команд, привычки и экосистемной патологии, где библиотеки стали стандартом. Web Components имеют плохо продуманный API, требующий обёрток вроде Lit для практического использования. Нативные элементы <datalist> и <dialog> часто ненадёжны или ограничены в браузерах (особенно Firefox и Safari), что вынуждает писать кастомные решения. Safari остаётся проблемой из-за привязки обновлений к версиям ОС, делая новые API недоступными для значительной части пользователей даже после стандартизации. UX-дизайнеры и продукт-менеджеры требуют кастомных интерфейсов (календарей, выпадающих списков), так как нативные элементы не соответствуют визуальным требованиям или не позволяют реализовать сложные сценарии. Многие разработчики выбирают кастомные решения не ради удовольствия, а потому что только они позволяют точно реализовать задуманное поведение, особенно в доступности и анимации. Спор: отсутствие полнофункционального searchable combobox с доступностью вынуждает создавать кастомные компоненты, делая зависимость от npm неизбежной — платформа учит работать вне себя. Спор: одни считают, что веб-платформа должна быть минимальной и композируемой (как Linux), другие — что она должна предоставлять готовые высокоуровневые компоненты, иначе разработчики изобретают велосипеды. Нативные API могут скрывать баги, проявляющиеся только в редких условиях, что делает их ненадёжными для продакшена и заставляет предпочитать контролируемые кастомные решения. Поколение разработчиков, выросшее на React, не знает нативных возможностей браузера и воспринимает работу с DOM как антипаттерн, закрепляя зависимость от фреймворков. Некоторые разработчики, вернувшиеся к vanilla JS + CSS, отмечают, что их приложения загружаются и работают быстрее, чем 99% сайтов с npm и сборкой, и не сталкиваются с ограничениями платформы. Совет: перед созданием кастомного компонента — исследовать, тестировать и оценивать нативные возможности, но не осуждать тех, кто пропускает эти шаги из-за сроков или сложности. Исторически многие стандарты (например, scroll-driven animations) появились не из спецификаций, а потому что разработчики сами создали и массово использовали паттерны, которые потом стандартизировали браузеры. В корпоративной среде многие разработчики просто не знают о существовании нативных элементов вроде <dialog> или <details>, что приводит к повторному изобретению колеса из-за отсутствия обучения. Использование платформы требует отказа от пожеланий продуктовых команд, что требует зрелости и понимания реальной стоимости кастомной разработки — навыка, которым обладают не все. Некоторые разработчики, использующие AI (например, Claude), создают сайты с минимальным JS, опираясь на нативные элементы, и достигают отличных результатов по весу и производительности, если приоритет — лёгкость.

Pi 1.0 — это стабильная версия минимального и расширяемого агента, который стал ежедневным инструментом для сотен тысяч пользователей по всему миру. Разработчики Earendil подчеркивают, что не гонятся за трендами, а внедряют только проверенные функции, взвешивая их полезность против добавленной сложности. В Pi 1.0 добавлены Codemode с нативной поддержкой MCP и работы с не-LLM моделями (например, Jev и изображениями), поддержка виртуальных моделей через расширения, отложенная загрузка инструментов, прогрев кэша для моделей Anthropic, системные сообщения mid-conversation (с учётом транскрипта), новая TUI-тема и полноэкранный режим по умолчанию. Все эти функции прошли длительное тестирование и теперь интегрированы без потери минималистичной сути Pi.

Параллельно с Pi 1.0 выпущен экспериментальный пакет Pi Durable — новый субстрат для создания долгосрочных агентных приложений, выходящих за рамки терминала и кодирования. Он сохраняет принципы минимализма и супермalleability Pi, но добавляет гибкость для управления интеллектом в длительных диалогах и задачах. Pi Durable позволяет пользователям направлять работу агентов с высокой точностью, например, через маршрутизацию между моделями: планирование на Claude Opus, переключение на GPT по сигналу Jev, выполнение скрипта и анализ стоимости по сессии. Примеры использования включают автоматическое суммирование недели коммитов, создание самописных расширений и динамическую смену моделей в ходе работы. Оба продукта распространяются под лицензией MIT, установка доступна через скрипт для Linux/macOS и PowerShell для Windows, а также через npm для Pi Durable. Документация и код находятся на pi.dev и GitHub соответственно.

Пользователи подтверждают, что Pi 1.0 — это минимальная, расширяемая платформа для агентных задач, где сила в экосистеме плагинов и способности работать с локальными моделями на слабом железе. Однако критикуют неоднородность качества плагинов и сомневаются в реальности утверждения о «сотнях тысяч» пользователей. Pi работает эффективно на слабых устройствах благодаря отсутствию громоздких системных промптов, в отличие от Claude и Codex, что подтверждают пользователи @FacelessJim и @girvo. Сила Pi — в экосистеме плагинов, но большинство из них — личные проекты с низкой поддержкой, как отмечает @richardgill88, что создаёт барьер для новичков. Спор о числе пользователей: некоторые сомневаются в утверждении о «сотнях тысяч» (@distantsounds), другие, как @lionkor и @by2kaapi, подтверждают повседневное использование Pi в продакшене и личных workflow. Спор о минимальности: @zmmmmm считает, что минимальность — оправдание отсутствия функций, в то время как @bel8 и @svintus хвалят сохранение простоты и отказ от трендов. Совет: начинать с минимальной настройки и постепенно расширять Pi (@ttmacer), используя tmux для отладки агентного поведения и Telegram для вывода. Совет: для безопасности запускать Pi в изолированных средах, например, через sbh + bubblewrap (@lionkor), чтобы ограничить доступ агента к системным ресурсам. Совет: пользователи, перешедшие с Claude Code, отмечают, что Pi упрощает синхронизацию конфигураций между агентами (@by2kaapi), избавляя от необходимости поддерживать одинаковые skills и MCP-настройки. Pi 1.0 — это скорее стабилизация API и прекращение ломающих изменений, чем добавление новых функций (@Jeeetendra), что подтверждает стабильность платформы для разработчиков. Совет: для тех, кто ищет более минимальные альтернативы, рекомендуют hax (@ltrg) — C-приложение с одним shell-инструментом и простой конфигурацией, без MCP. Многие пользователи, включая @ttmacer и @by2kaapi, используют Pi не только для кодирования, но и как общий агент для ОС — для управления файлами, логами, интеграции с CRM и автоматизации задач. Совет: пользователи, использующие Pi в продакшене, советуют строить харнесс поверх Pi SDK (@azuanrb), для централизации логов, мониторинга сессий и оценки моделей в реальном времени. Спор о различии от OpenCode: @browningstreet и @dom96 сомневаются в ценности перехода, в то время как @by2kaapi и @azuanrb отмечают превосходство Pi в гибкости и вендор-агностичности. Pi Durable воспринимается как инструмент для создания фоновых агентов в инфраструктуре, а не только для пользовательских интерфейсов (@sheepscreek), например, для мониторинга фаервола с аудитом. Совет: пользователи, использующие локальные модели (Qwen 3.8, GPT Luna), отмечают, что Pi позволяет эффективно запускать их без траты токенов (@skapadia, @girvo), что делает его экономически выгодным. Спор: критики указывают на несогласованность критериев «доказанности» функций: MCP поддерживается, хотя существует два года, а Jev — только месяц — и уже включён (@hhh), что вызывает недоверие к философии минимальности.

Pi Durable — это фреймворк для создания долгоживущих, устойчивых к сбоям и гибких агентов, способных работать в любой среде с JavaScript-рантаймом. Он не заменяет Pi как код-агента, а предоставляет универсальную основу для построения агентных приложений, включая самого Pi. Фреймворк построен на принципах минимализма и изменяемости, делится кодом с Pi (например, pi-ai), и позволяет экспериментировать с новыми архитектурами без риска для основного продукта. Весь исходный код без тестов составляет около 15 000 строк (150–250 тыс. токенов), но для большинства задач достаточно меньшей части — например, хранилища занимают всего 3 000 строк и легко подменяются.

Харнесс в Pi Durable — это сочетание хранилища и механизма для параллельного запуска множества разговоров с LLM. Он предоставляет инструменты, которые модели могут вызывать, и среды их выполнения (локальная машина, удалённая VM, песочница). Разговор — это транскрипт взаимодействия пользователя с агентом (LLM + настройки + инструменты). Каждый вызов модели или инструмента — это задача. Хранилище может быть in-memory, SQLite или JSONL, с возможностью подключения собственных бэкендов через простой интерфейс. На SQLite активные данные (транскрипты, задачи, отправки) держатся в памяти, а остальное — на диске, что обеспечивает эффективность и устойчивость к сбоям. Один процесс владеет хранилищем, другие клиенты подключаются к нему.

Pi Durable поддерживает бесконечно длинные диалоги, выживает при катастрофических сбоях и позволяет нескольким людям управлять одним агентом одновременно. Пример — агент для планирования отпуска (~1300 строк TypeScript, mostly TUI), который демонстрирует параллельный поиск (погода, музеи, поезда), устойчивость к перезапуску (только незавершённые задачи повторяются), переключение между суб-агентом и главным, и автоматическое формирование плана из результата. Для запуска достаточно собрать проект и выполнить две команды; для использования в своих проектах — установить три пакета через npm. Выбор TypeScript обусловлен простотойbootstrap, но порт на Rust или ассемблер не исключён в будущем.

Обсуждение подтверждает практическую ценность Pi Durable для длительных задач: аналитика, мониторинг cron‐задач, автоматическое создание PR и ежедневный триаж алертов. Pi Durable не предоставляет встроенный sandbox; разработчики должны подключать собственный (например, Gondolin от Earendil) в соответствии с политиками. Спор: одни считают фреймворк должен быть sandbox‐агностичным, другие видят отсутствие first‐class sandbox‐а недостатком. Разговоры в Durable реализованы как линейный список записей с указателем на предшествующий (fork); ветвление дерева заменено плоской структурой. requestId используется как ключ идемпотентности для exactly‐once, но некоторые считают, что одного ID недостаточно. Токенизация кода зависит от модели: 15 000 строк ≈ 150 000 токенов GPT и 250 000 токенов Claude. Создание хранилища, координирующего несколько экземпляров vanilla Pi, сложно и может превзойти выгоды от durability. Для синхронизации внешних хранилищ с состоянием разговора рекомендуется задача‐синхронизатор (например, SyncToPostgres). Многопользовательский режим отмечен как важный плюс для удалённых контрольных инструментов. Durability достигается хранением JSON‐документов локально и минимизацией объёма данных в памяти. Совет: не «запекать» инструменты по умолчанию; лучше предоставить профиль с опцией включения нужных. Совет: добавить полити‐движок для sandbox‐ов (например, интеграция с NVIDIA openshell). Pi Durable позиционирует себя как более агностичный по сравнению с LangChain, Vercel Eve, OpenAI Agents и другими решениями. Вопрос синхронизации состояния агента и состояния VM/контейнера остаётся открытым. Жалобы на читаемость шрифта кода в статье не относятся к техническим аспектам.

Netlify перестроила инфраструктуру Edge Functions, заменив V8 изоляты на Firecracker MicroVMы в сотрудничестве с Unikraft, что ускорило среднее время выполнения с 25–40 мс до 5–6 мс — почти в 5 раз. Теплые вызовы теперь занимают ~5–6 мс (p50), а p99 стал на 47,4% быстрее, при этом доступность достигла 99,998%, а доставка логов ускорилась в 5 раз. Холодные старты происходят в 1,2% случаев и занимают в среднем 9 мс, так как требуют загрузки образа VM перед выполнением.

Запрос проходит через ближайший edge-узел, где проверяется маршрут Edge Function; при совпадении запрос направляется внутрь собственной сети Netlify на выделенный compute-узел, где запускается либо уже существующая, либо новая MicroVM с файловой системой и полным Linux-окружением. Управление флотом узлов осуществляется через контрольную плоскость, которая обеспечивает обновления без простоев: новый флот выводится рядом со старым, проверяется на здоровье и постепенно принимает трафик. Эта архитектура сохраняет полную обратную совместимость — импорты через URL, npm-пакеты, Node.js built-ins, netlify.toml и локальная разработка работают без изменений — но открывает путь к снятию прежних ограничений: поддержка npm-пакетов выходит из бета, пересматриваются лимиты на CPU (50 мс), память (512 МБ) и размер кода (20 МБ), а также появляется возможность выполнять сложные вычисления, требующие контроля над сетевым путем, без выхода в публичный интернет.

Ускорение Netlify с 25–40 мс до 5–6 мс связано с переносом вычислений из внешней хостинговой инфраструктуры в собственную сеть, а не с самой технологией выполнения. Firecracker используется для изоляции и безопасности, но не заменяет Docker — запуск полной ОС в VM считается избыточным для многих задач из-за большего rootfs и зависимости от KVM. V8 изоляты не считаются надёжной изоляцией в эпоху ИИ — Chrome сам им не доверяет, поэтому требуются дополнительные слои безопасности. Firecracker — технология AWS, её использование Netlify подтверждает универсальность, но AWS Lambda остаётся медленнее из-за enterprise-слоёв, а не микровиртуализации. Холодные старты в 1,2% случаев и p50 ~5–6 мс у Netlify значительно лучше, чем у AWS Lambda (задержки до 1500 мс), несмотря на общую технологию. Спор: Cloudflare Workers быстрее, потому что их исполнение всегда внутри сети, а у Netlify ранее — нет. Создание снапшотов MicroVM после загрузки JS-сервера может вызывать проблемы с RNG и криптографией, но Firecracker имеет решения. AOT-компиляция может улучшить производительность, но не распространена в serverless-экосистеме. Fetchable API в Netlify Edge Functions не реализована, несмотря на наличие эксперта в компании. Netlify использует unikernels на базе Firecracker (через Unikraft) для минимизации образа и ускорения загрузки. Firecracker + Unikraft могут быть оптимальны для запуска ненадёжного кода на AWS — обсуждается как потенциальное решение. Firecracker для Edge Functions не заменяет контейнеры — это разные инструменты: VM для изоляции, контейнеры для эффективности, их можно комбинировать (например, Kata). Netlify перешёл от внешнего хостинга к собственной инфраструктуре — это дало прирост скорости; Firecracker обеспечил безопасность и контроль.

Reladraw — это текстовый язык для создания диаграмм с точным, но гибким позиционированием элементов. В отличие от Mermaid или Graphviz, где расположение автоматизировано, и draw.io, где нужно вручную перетаскивать узлы, Reladraw позволяет задавать относительные позиции: below, right of, level with — без ручного указания координат. Например, диаграмма архитектуры из 10 узлов и связей описывается всего 7 строками кода, что делает её легко редактируемой и версионируемой. Результат рендерится в SVG без внешних зависимостей.

Инструмент доступен как CLI-утилита через npm install -g reladraw и интегрируется с AI-агентами (Claude, Copilot и др.) через плагины. На данный момент версия 0.11.1 — ранняя, с нестабильным синтаксисом, но уже работает: парсер, движок макета и рендерер написаны на TypeScript. Проект открыт для обратной связи — особенно ценятся примеры диаграмм, которые невозможно выразить текущим синтаксисом. Лицензия Apache-2.0, но торговая марка «reladraw» не включена в разрешения.

Обсуждение подтверждает, что необходимость точного позиционирования в диаграммах действительно существует и Reladraw закрывает этот пробел, однако пользователи указывают на баги (тёмные темы, кривые стрелки), просят интеграцию в markdown и IDE, а также сравнивают его с D2/TALA и задаются вопросом, стоит ли создавать новый язык или расширять существующие инструменты вроде Mermaid.

• Большинство комментаторов считают, что текущие инструменты (Mermaid, Graphviz, draw.io) либо автоматизируют расположение, либо требуют ручного перетаскивания, и поэтому им не хватает детального контроля, который предоставляет Reladraw.

• Относительные позиции (below, right of, level with) воспринимаются как достаточный уровень точности для большинства диаграмм, избавляя от необходимости указывать абсолютные координаты.

• Совет: Разработчикам рекомендуется создать плагины для популярных редакторов (VS Code, Obsidian) и поддержать блоки кода ```reladraw в markdown, чтобы упростить использование в документации.

• Совет: Полезно отделить топологическую часть языка (стрелки, группы) от инструкций по расположению, что позволит использовать Reladraw как слой раскладки для других DSL, например C43.

• В обсуждении отмечены баги: некорректный рендер кривой стрелки при указании from/to и проблемы с переключением тем в Safari, где тёмный фон делает текст нечитаемым.

• Совет: Необходимо добавить поддержку тем и исправить рендеринг в разных браузерах, а также обеспечить более стабильный веб‐интерфейс перед выпуском.

• Некоторые пользователи упомянули D2 с открытым движком TALA, который уже предоставляет ручной контроль над расположением и иногда генерирует более качественные макеты, чем Mermaid.

• Спор: Одна сторона считает, что вместо создания нового языка следует добавить ограничения размещения в Mermaid, чтобы не фрагментировать экосистему; другая сторона аргументирует, что только отдельный язык может гарантировать детерминированный результат без вмешательства движка раскладки.

• Есть интерес к автоматическому преобразованию описаний архитектуры, сказанных устно, в Reladraw‐диаграммы, что может облегчить взаимодействие с AI‐агентами.

• Совет: Рассмотреть возможность импорта/экспорта из/в форматы draw.io, чтобы пользователи могли мигрировать существующие схемы в Reladraw без потери информации.

This is very needed in the AI coding age! I find diagramming is one of the best ways for high bandwidth alignment between my mental model and the agent’s. I have been working on this problem a bit as I see good visuals as a key bottleneck in faster development while maintaining a real… — @apinstein

htmx 4.0.0 вышел после восьми месяцев разработки, сосредоточившись на стабильности и будущей долговечности — с целью создания веб-сервисов, работающих 100 лет. Главное изменение: атрибуты больше не наследуются автоматически, а требуют явного указания через :inherited (например, hx-confirm:inherited), что устраняет неочевидное поведение из прошлых версий. Для миграции доступен инструмент командной строки, автоматически находящий места, где нужно добавить :inherited.

Внутренне библиотека перешла с XMLHttpRequest на современный fetch(), что упростило код и позволило реализовать стриминг HTML. Имена событий стандартизированы, а поддержка истории больше не использует localStorage, убрав частые проблемы с отладкой. Несмотря на изменения, поведение 4.0 почти идентично 2.x — обновление необязательно: NPM оставит 2.x как latest, пока 2027 год. Для разработчиков, использующих LLM, выпущены специальные файлы с руководствами по миграции, отладке и написанию расширений.

Тред в основном поддерживает релиз, но добавляет несколько практических наблюдений: реальный опыт миграции с Turbo/Hotwire на htmx 4 в Rails-приложении (@dajonker), сочетание с agent-driven разработкой благодаря простой HTML-разметке (@bluesnowmonkey, @arjie), подтверждение востребованности обновлённой совместимости с Alpine через alpine-ajax (@james2doyle), а также контраргумент из .NET/Angular-стека о возврате к смешению UI и бизнес-логики (@rednb). Шутка про «CEO of HTMX» стала мемом треда.

• htmx ценят за простоту, низкий порог входа и органичный рост без корпоративных амбиций; многие отмечают, что агенты и vibe-coding отлично работают с гипермедийным HTML, потому что UI можно тестировать без headless-браузера (@bluesnowmonkey, @arjie, @havaloc, @nzoschke).

• Наследование атрибутов через явный `:inherited` воспринимается как спорное, но потенциально полезное для читаемости (@jamesforestwest, @ryanisnan отмечает, что кроме статического HTML лучшей альтернативы для «100-летнего веба» он не видит).

• Совет: @james2doyle на практике заменил htmx связкой Alpine.js + alpine-ajax (~10 КБ), получив все нужные фичи и обойдя проблемы совместимости hx-alpine-compat.

• Совет: @dajonker в проде на Rails заменил большую часть Hotwired/Turbo на htmx 4, используя ActionCable для пушей вместо Turbo Streams, и отмечает, что с htmx поток контента управляется с клиента, а не с сервера.

• Спор: @rednb, опытный .NET+Angular разработчик, считает htmx шагом назад: возврат к генерации UI на бэкенде смешивает presentation с бизнес-логикой, а серверное управление состоянием в нетривиальных SPA сложнее TypeScript. Ему возражают сторонники SSR-подхода (@nzoschke: Go+htmx+SQLite как простой и быстрый стек), показывая, что «шаг назад» зависит от класса задач.

• alpine-ajax и Datastar упоминаются как реальные альтернативы/дополнения к htmx (@james2doyle, @threesmegiste: Datastar вырос из идей htmx, @teknico).

• Спор: @replwoacause сомневается в долгосрочной ценности htmx в эпоху LLM, которые могут генерировать JS напрямую; @threesmegiste и @ryanisnan контраргументируют, что простота и независимость от JS-цепочек инструментов остаются преимуществами, особенно для долгоживущих сервисов.

• Совет: Несколько пользователей (@cubefox, @hollowturtle) сообщают о практическом баге: якорные ссылки в секции «On this page» ломаются на Mobile Safari и Android Firefox/Chrome — регрессия 4.0.0, не упомянутая в статье.

• Мем треда — самопровозглашённые «CEO of HTMX» (@Baguette5242, @dec0dedab0de, @hmokiguess, @miguel-muniz, @alkonaut), породивший шутку про домен htmx.ceo и реплику «у нас больше CEO, чем пользователей» (@alkonaut).

• Совет: @praseodym и @orsenthil независимо заметили, что обложка релиза (джип) совпадает с обоями Omarchy Quattro/DHH; @alsanan напоминает, что истинный драйвер 4.0 — проект fixi того же автора, более минималистичный преемник.

Инструмент @openai/codex-security — это CLI и TypeScript‑SDK, позволяющие обнаруживать, проверять и исправлять уязвимости в коде. Требуется Node 22 или новее и Python 3.10 +, а также доступ к Codex Security. Установка через npm i @openai/codex-security, вход командой npx codex-security login и сканирование репозитория npx codex-security scan .. Для CI можно использовать переменную OPENAI_API_KEY вместо входа, а при наличии обоих учетных записей интерактивный скан запрашивает выбранный метод; в неинтерактивных режимах приоритет остаётся у API‑ключа. Параметр --auth chatgpt или --auth api-key позволяет явно указать источник.

Результаты сканирования сохраняются в рабочем каталоге Codex Security; если запись недоступна, задайте CODEX_SECURITY_STATE_DIR на записываемую директорию. Для работы с TypeScript‑SDK импортируют CodexSecurity из пакета, создают экземпляр, вызывают run('.'), выводят reportPath и закрывают соединение close(). Всё необходимое о параметрах сканирования, настройке CI и дополнительных опциях описано в официальной документации. Интересный факт: при конфликте учётных данных интерактивный режим предлагает выбрать источник, а в автоматизированных пайплайнах предпочтение отдаётся API‑ключу, что упрощает интеграцию в существующие workflow. Кроме того, можно фильтровать результаты по уровню угрозы через --severity и экспортировать отчёт в JSON для дальнейшего анализа.

Тред обсуждает практический опыт использования Codex Security: пользователи отмечают высокие затраты и ограничения по скорости запросов, что может быть проблемой для крупных проектов. Есть споры о его эффективности — одни считают инструмент полезным для обнаружения уязвимостей, другие сомневаются в его способностях. Рекомендуется использовать опцию --max-cost для контроля расходов. Codex Security сравнивают с Snyk и Strix, обсуждая его потенциальное влияние на рынок безопасности.

Perl не мёртв, его популярность находится на уровне периода dotcom пузыря, согласно отчёту CPAN 2023. Новичков среди пользователей Perl становится всё меньше с 2011 года, хотя общее использование языка остаётся стабильным. Raku (бывший Perl 6) не стал причиной упадка, так как Perl продолжал расти даже во время разработки Raku.

Основные гипотезы упадка Perl связаны с изменением поколений программистов и развитием инструментов разработки. Программисты, выросшие на Unix-системах, естественно воспринимали Perl как продолжение shell, C, awk и sed. Новое поколение, воспитанное на Microsoft, Visual Basic и Java, предпочло Python. Кроме того, появление мощных менеджеров пакетов сделало доступными множество альтернатив, в то время как раньше Perl был одним из немногих доступных инструментов.

• Perl умер не из-за Raku, а из-за отсутствия единого пути развития, отсутствия стандарта кодстайла и культуры «один-разовых» скриптов.
• Python и PHP выиграли, потому что они были «дружелюбнее» для новичков и имели лучшую документацию.
• CPAN стал менее удобным, чем PyPI и npm, что сделало Perl менее привлекательным.
• Отсутствие единого фреймворка для веб-разработки и отсутствие стандарта ООП в Perl 5.
• Не было единого сообщества, которое могло бы продвигать Perl, в то время как Python и JavaScript имели Google и Facebook.

Инструмент 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) и необходимость улучшения документации, особенно для новичков.

Обнаружена первая вредоносная реализация MCP-сервера в дикой природе — пакет postmark-mcp, который с версии 1.0.16 тайно копирует все отправляемые письма на внешний сервер злоумышленника. Пакет скачивался 1500 раз в неделю и интегрировался в рабочие процессы разработчиков, получая полный доступ к почтовым данным, включая сбросы паролей, конфиденциальные документы и финансовые отчеты.

Атака основана на имперсонации: злоумышленник скопировал код официального репозитория Postmark, добавил скрытую строку BCC и опубликовал под тем же именем в npm. Уязвимость оставалась незамеченной, так как MCP-серверы работают вне периметра безопасности, обходя системы контроля DLP и инвентаризации активов. Это демонстрирует растущие риски supply-chain-атак через инструменты ИИ, которые получают привилегии без должной проверки.

• Участники обсуждают риски использования сторонних пакетов и инструментов, проводя параллели с историческими проблемами безопасности, такими как уязвимости в почтовых клиентах или SQL-инъекции.
• Высказываются предположения, что инцидент с пакетом postmark-mcp мог быть не злонамеренной атакой, а случайной ошибкой разработчика, оставившего отладочный код.
• Поднимается вопрос о доверии к ИИ-инструментам и MCP-серверам, которые получают чрезмерные права доступа к данным без должного контроля со стороны пользователей.
• Критикуется практика публикации статей, обработанных ИИ, что затрудняет восприятие и проверку фактов, а также общая культура безопасности в разработке, где скорость часто важнее надежности.
• Обсуждается ответственность платформ (например, npm) и необходимость более строгих правил для предотвращения подмены пакетов и supply chain-атак.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

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

С тех пор произошло множество инцидентов, и конкретно NPM стал крупнейшим и самым простым способом распространения вредоносного ПО. Сначала большинство атак было направлено на кражу криптовалюты (поскольку техбро одержимы магическими электрическими деньгами и являются лёгкой добычей). Но теперь эти атаки на цепочку поставок нацелены на более критичные вещи, такие как токены и ключи доступа maintainers пакетов, как видно из инцидента с NX и теперь несколькими зависимостями, ежедневно используемыми тысячами разработчиков.

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

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

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.

Компрометация пакетов ctrl/tinycolor и 40+ других в NPM

Популярный пакет @ctrl/tinycolor с более чем 2 млн загрузок в неделю был скомпрометирован вместе с 40+ другими пакетами в результате сложной атаки на цепочку поставок. Вредоносное ПО самораспространяется по пакетам maintainer'ов, собирает учетные данные AWS/GCP/Azure с помощью TruffleHog и создает бэкдоры через GitHub Actions.

Технический анализ

Атака реализуется через многоступенчатую цепочку, использующую Node.js process.env для доступа к учетным данным. Основной элемент — файл bundle.js (~3.6 МБ), который выполняется асинхронно во время npm install.

Механизм самораспространения
Вредоносное ПО через функцию NpmModule.updatePackage запрашивает API реестра NPM для получения до 20 пакетов maintainer'а и принудительно публикует обновления, создавая каскадный эффект компрометации.

Сбор учетных данных
Используются инструменты вроде TruffleHog для сканирования файловой системы на наличие секретов. Целевые учетные данные включают:

• Токены доступа GitHub
• Ключи доступа AWS
• Учетные данные Google Cloud Platform

• Пользователи выражают обеспокоенность невозможностью аудита всех зависимостей и их уязвимостью к атакам в npm.
• Критикуется архитектура npm, в частности выполнение postinstall-скриптов по умолчанию, в отличие от других менеджеров пакетов.
• Предлагаются решения: игнорирование скриптов в настройках, песочница (bubblewrap), использование подписей кода и каррированных пакетов.
• Указывается на системную проблему экосистемы JS: огромное количество мелких зависимостей и отсутствие сильной стандартной библиотеки.
• Обсуждается масштаб атаки (180+ пакетов) и её возможная связь с государственными акторами.
• Поднимается вопрос уязвимости других экосистем (PyPI) и необходимости обязательной 2FA и подписи артефактов.
• Высказываются радикальные предложения по замене npm или созданию безопасного форка/дистрибутива пакетов.

Как устроен bun install

• Один бинарник — весь менеджер зависимостей живёт внутри Bun, нет внешних вызовов к npm, yarn, node-gyp.
• Сишный движок — парсинг package.json, yarn.lock, node_modules происходит на Zig, без JS-оверхеда.
• HTTP-пул + кэш — 50–100 параллельных потоков, кэш на диске + SQLite-индекс, повторный install — <100 мс.
• Symlink-ферма — модули не копируются, а hard-link’ются из глобального кэша; экономия 70 % диска.
• Муравьиный алгоритм — сначала скачиваются «листья» дерева зависимостей, потом родители; сеть греется максимально.
• Платформенные пакеты — если в lock-файле есть запись под Linux, macOS и Windows, скачиваются сразу три архива и раскладываются в node_modules/.cache, при запуске выбирается нужный.
• postinstall без shell — скрипты запускаются встроенным JS-движком, нет overhead’а на spawn bash/cmd.
• Проверка целостности — каждый tarball сверяется по SHA256 из lock-файла, кэш защищён от подмены.
• Мониторинг прогресса — терминал обновляется раз в 16 мс, рисуется ASCII-полоса и счётчик «пакетов/сек».
• Фоллбек к npm — если пакет не найден в официальном реестре, Bun автоматом лезет в npm и кладёт tarball в кэш, пользователь не замечает разницы.

• Пользователи обсуждают статью о внутреннем устройстве и производительности менеджера пакетов Bun.
• Многие хвалят скорость и простоту Bun, но отмечают проблемы совместимости с Node.js и стабильностью.
• Часть комментаторов сомневается в практической пользе высокой скорости установки пакетов и считает переход с Node.js рискованным.
• Упоминаются альтернативы — Deno, pnpm, npm — и сравнение с ними по скорости и надёжности.
• Некоторые считают, что Bun не предлагает «убийственных» фич, чтобы оправдать переход с зрелой экосистемы Node.js.

Коротко: в NPM проникли популярные пакеты (colors, debug и др.) через фишинг письмо «смени 2FA». Вредоносный код подменял адреса криптокошельков.
Почему это мелко: библиотеки используются в CLI-утилитах, а не в Web3; украденные API-ключи или майнеры были бы катастрофой.
Вывод: любая зависимость может быть трояном, но проверять всё дерево пакетов никто не успевает — надо успевать релизить.

• Атака на NX через NPM показала, что даже популярные плагины могут стать вектором для кражи creds и API-кейсов.
• Участники сходятся: «всё дерево зависимостей NPM по умолчанию доверяет всем», а ручная проверка каждой мелкой библиотеки невозможна при скорости релизов.
• Многие выжили лишь благодаря «отложенным обновлениям», изоляции в контейнерах или отказу от экосистемы Node/NPM целиком.
• Фишинг на домене npm.help подтвердил, что даже IT-специалисты не всегда замечают поддельные TLD; предлагают белые списки ссылок и DMARC-индикаторы в клиентах.
• Утверждение «мы просто не заметили более продвинутые атаки» звучит всё чаще: Jia Tan 3.0, по мнению комментаторов, уже где-то в supply-chain.

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

Пакетные менеджеры — зло

Пакетные менеджеры автоматизируют ад зависимостей: скачивают пакет → его зависимости → зависимости зависимостей… и ты в аду. Вручную хотя бы думаешь: «а надо ли?»

Большинство языков не знают, что такое «пакет», поэтому менеджер сам его придумывает. В итоге появляются «менеджеры менеджеров» (npm, yarn, pnpm…).

Языки с толстой стандартной библиотекой (Go, Odin) откладывают ад: 90 % задач решаются без сторонних пакетов.

Каждая зависимость — это долг: баги, security, поддержка. Мы взяли SDL2 — и год убили на чужие баги; проще написать своё, чем обновиться до SDL3.

Доверие к случайному коду из интернета — социальная болезнь программистов.

• Критика менеджеров пакетов сводится к тому, что они «автоматизируют ад зависимостей», скрывая от разработчика реальные издержки и риски.
• Автор предлагает вручную копировать и фиксировать нужные версии библиотек, чтобы осознанно контролировать, что именно попадает в проект.
• Оппоненты считают идею регрессом: ручное управление не масштабируется, тормозит разработку и не решает проблему транзитивных зависимостей.
• Поддержка Cargo, npm и прочих инструментов признаётся необходимой, но критикуется культура «микро-зависимостей» и отсутствие вендоринга.
• Компромисс видят в строгом вендоринге (Google), фиксации версий, feature-gates и использовании «batteries-included» стандартных библиотек (Go).

FuckUpMySite — преврати любой сайт в хаос.

• Деструкция: 0 %
• Лозунг: fuckfuckfuckfuckupupupupmymymymysitesitesitesite
• Девиз: «Некоторые просто хотят смотреть, как горит веб».

Попробуй на: Sentry.io, Hacker News, Apple, Stack Overflow
Кнопка: «FUCK THIS SITE UP»

😈 Настройки хаоса

(3 из 6 активны)

• 🔥 Пылающий курсор — курсор поджигает страницу
• 🤪 Comic Sans всё — весь текст Comic Sans
• 👻 Фальшивые курсоры — множество поддельных теней
• 🪰 Назойливая муха — жужжит по экрану
• 🏃 Убегающие кнопки — прячутся от мыши
• 🔨 Попап-лопатка — ложные окна, которые нужно закрывать

Не все сайты дружат с хаосом. Нашёл баг? Напиши в Twitter.

• Участники обсуждают сайт-шутку, который «ломает» любую страницу: Comic Sans, ползающие жуки, огонь и т.д.
• Браузеры (Chrome, Firefox, Safari) блокируют его как «опасный», что вызывает смех — предупреждение идеально вписывается в дух проекта.
• Некоторые сравнивают его с Katamari Hack, Desktop Destroyer, netdisaster и старыми оверлеями 90-х.
• Работает не везде: падает на Whitehouse.gov, opennet.ru, сайтах с Anubis, а также на самом себе.
• Люди делятся ссылками на «испорченные» версии Fox News, Apple и др.; кто-то просит npm-пакет для розыгрыша.

Open Source — это один человек
Сокращённый перевод поста Джоша Брессерса

Публикация The Register, высмеивающая российского разработчика за то, что его утилита используется Пентагоном, — позор. На самом деле почти всё open-source ПО в мире пишут одиночки.

Проект ecosyste.ms индексирует 11,8 млн репозиториев. Из них 7 млн обслуживает один человек. Ещё 4 млн — данные о количестве мейнтейнеров отсутствуют, но большинство из них тоже «одиночки».

В экосистеме NPM картина та же:

• 4 млн пакетов → ~900 тыс. авторов (один человек — много проектов).
• Среди 13 тыс. самых скачиваемых пакетов (>1 млн загрузок в месяц) почти половина поддерживается одним человеком.
  Только при пороге в 1 млрд загрузок большинство проектов имеют команду >1 человека.

Вывод

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

Что делать? Однозначного рецепта нет, но начать стоит с признания проблемы и поддержки мейнтейнеров, а не травли.

• Проблема рисков цепочки поставок в OSS — это не инженерный, а управленческий вопрос: один автор, даже без злого умысла, создаёт уязвимость.
• Большинство пакетов NPM — одноразовые проекты одного человека; половина вообще не имеет активных мейнтейнеров.
• При «кончине» единственного мейнтейнера проект либо умирает, либо его форкают, либо приходит замена — зависит от размера аудитории и сложности кода.
• Критика статьи: автор путает скачивания CI/CD с реальным использованием, игнорирует реальное число контрибьюторов и подменяет статистику.
• DoD, как и любая крупная организация, использует Node/NPM для низкокритичных задач, а критичный код вендорится и аудируется.

Суть проблемы
В npm-реестр попали вредоносные версии пакетов Nx и связанных плагинов. Злоумышленники использовали временный доступ к npm-аккаунту @nxscope и опубликовали поддельные версии 19.8.0–19.8.2.

Затронутые пакеты

• nx
• @nx/angular, @nx/cypress, @nx/detox, @nx/devkit, @nx/esbuild, @nx/eslint-plugin, @nx/expo, @nx/express, @nx/jest, @nx/js, @nx/nest, @nx/next, @nx/node, @nx/playwright, @nx/plugin, @nx/react, @nx/rollup, @nx/storybook, @nx/vite, @nx/web, @nx/webpack, @nx/workspace

Что делать

1. Удалить вредоносные версии.
2. Установить официальные 19.8.3 или выше.
3. Проверить lock-файлы и CI на наличие подозрительных версий.

• Уязвимость в пакетах Nx: токен npm скомпрометирован, злоумышленники внедрили вредоносный код через post-install скрипты.
• Малварь ищет Claude Code / Gemini CLI и использует их как «живые» инструменты для поиска криптокошельков, ключей и других секретов.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать Bun (по умолчанию не запускает скрипты), Verdaccio для вендоринга и инструмент vet для сканирования.
• Рекомендуют разрабатывать в изолированных контейнерах/VM (cubbi, bubblewrap, firejail) и пересматривать каждую зависимость вместо «npm install наугад».
• Основной вывод: современные цепочки поставок и AI-агенты создают новый вектор атак «prompt-as-malware», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.

Lazy Brush — библиотека для рисования плавных линий мышью, пальцем или любым другим указателем.
GitHub | npm | Reddit

Параметры:

• Lazy radius (60 px) — минимальное расстояние, при котором кисть тянется к курсору.
• Friction (0.10) — инерция: 0 — без задержки, 1 — бесконечная.
• Brush radius (13 px) — толщина кисти, не влияет на логику.

Автор: dulnan

• Библиотека Perfect Freehand и её демо drawmote от автора TLDRaw признаны лучшей альтернативой для плавных подписей и рисования.
• Техника «ленивого» курсора с гистерезисом/стабилизатором уже применялась в Wii-играх, Krita, ZBrush, Black & White и других графических пакетах.
• Пользователи отмечают, что визуальный «поводок» между курсором и пальцем делает рисование интуитивным, особенно на мобильных устройствах и при работе мышью.
• Некоторые считают задержку слишком большой и предлагают использовать фильтр Калмана или DynaDraw для меньшего лага.
• Проект вызвал восторг («лучшее бесплатное», «шокирующе хорошо»), но кто-то жалуется на пропадающие линии и невозможность «естественных» штрихов.

• Установка: npm i -g cursor-cli
• Команды: cursor diff, cursor commit, cursor review, cursor chat
• Где работает: VS Code, JetBrains, Android Studio, Ghostty, Warp, Bash

Функции

• Прямые правки кода в терминале
• Реальное управление агентом
• Правила через .cursorrules, AGENTS.md, MCP

Плюсы

• Последние модели Anthropic, OpenAI, Gemini
• Интеграция в любой IDE
• Скрипты и автоматизация

• Пользователи обсуждают внедрение единого стандарта AGENT.md вместо множества разных файлов.
• CLI-агенты (Claude Code, Cursor CLI и др.) вызывают восторг: удобно держать в фоне, «чувствуешь себя хакером», но UI-IDE теряет значение.
• Критика: непонятно, зачем платить за Cursor, если тот же функционал уже включён в подписку Anthropic/OpenAI; не хватает обратной связи, MCP, hooks и локальных моделей.
• Сторонники Cursor верят в его будущую экосистему (CLI + IDE + GitHub-интеграции) и низкие издержки переключения между моделями.
• Главный вопрос безопасности: доверять ли LLM полный доступ к файловой системе и устанавливать скрипты через curl | bash.