Cloudflare представила Oxy - новый прокси-фреймворк, написанный на Rust, который служит основой для нескольких ключевых продуктов компании, включая Zero Trust Gateway и iCloud Private Relay. Разработанный с учетом опыта создания высоконагруженных прокси, Oxy позволяет реализовывать современные протоколы связи и строить сложные сервисы для обработки огромного трафика.

Фреймворк предоставляет программный контроль над всеми аспектами проксирования: от декапсуляции протоколов и анализа трафика до маршрутизации и DNS. Oxy тесно интегрирован с внутренней инфраструктурой Cloudflare, но при этом настраивается под нужды приложений. Инженеры могут начать с базового решения, которое не требует написания кода, и постепенно добавлять функции через расширяемые точки. Например, для создания HTTP-файрвола достаточно реализовать обработчики запросов и ответов, а для L4-файрвола - добавить аутентификацию или георouting.

• Обсуждение в основном вращается вокруг негативного опыта с Cloudflare Tunnels и их IPv6-ограничений, а также сравнения с другими решениями вроде Tailscale и ngrok.
• Участники жалуются на плохую документацию, отсутствие прозрачности и "vendor lock-in" при использовании продуктов Cloudflare.
• Обсуждение также затрагивает вопросы лицензий, сравнение с другими решениями и влияние на разработчиков.
• Некоторые участники делятся личным опытом и альтернативными инструментами вроде localtunnel и Tailscale.
• В целом, обсуждение подчеркивает сложность выбора между удобством и контролем над инфраструктурой, особенно в контексте разработки ПО.

Debian планирует внедрить обязательные зависимости от Rust в APT не ранее мая 2026 года. Изначально это коснется компилятора Rust, стандартной библиотеки и экосистемы Sequoia. Разработчики отмечают, что код для парсинга .deb, .ar, .tar файлов и верификации HTTP-подписей значительно выиграет от использования безопасного с точки зрения памяти языка и улучшенного подхода к юнит-тестированию.

Мейнтейнерам портов без работающего инструментария Rust дано 6 месяцев на внедрение поддержки, в противном случае их порты будут закрыты. "Важно для проекта в целом иметь возможность двигаться вперед и полагаться на современные инструменты и технологии, а не быть сдерживаемыми попытками втиснуть современное ПО на ретро-устройства", — говорится в сообщении. Это решение отражает стратегический сдвиг Debian в сторону повышения безопасности и надежности системных компонентов.

• Дискуссия вокруг требования к Rust в Debian выявил, что спор касается не только безопасности, но и поддержки архитектур, лицензий и долгосрочной стабильности.
• Участники обменялись взаимными обвинениями в «религиозной вовлечённости», «попытке монополизировать инфраструктуру» и «попытке вытеснить C и C++».
• Некоторые участники подняли вопрос о том, что выбор языка программирования не должен быть предметом политики, а также о том, что влияние на совместимость с другими архитектурами и надежность инструментария.
• Обсуждение также затронуло вопрос о том, какие именно архитекруры считаются "живыми", и как это влияет на поддержку устаревших систем.
• В конце концов, участники согласились, что важно сохранить возможность выбора инструментария для разработки, но при этом не забывать о практических последствиях такого выбора.

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

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

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

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

Google анонсировал, что с выходом Chrome 154 в октябре 2026 года включит по умолчанию функцию "Always Use Secure Connections", требующую разрешения пользователя для доступа к сайтам без HTTPS. Эта мера призвана защитить пользователей от атак, при которых злоумышленники могут перехватить навигацию и подменить контент. Хотя HTTPS-адoption достиг 95-99%, прогресс застыл с 2020 года, а оставшиеся HTTP-соединения все еще представляют значительную угрозу.

Для баланса безопасности и удобства Chrome не будет дублировать предупреждения для часто посещаемых HTTP-сайтов. Google подчеркивает, что даже небольшая доля небезопасных соединений создает риски, так как атакующему достаточно одного успешного перехвата. Компания отмечает, что за десятилетие наблюдений HTTPS стал зрелым и широко распространенным, что позволяет теперь перейти к более строгим мерам защиты по умолчанию.

• Пользователи обсуждают, что почти весь трафик уже давно перешёл на HTTPS, и оставшиеся HTTP-сайты — это в основном старые ресурсы, которые не обновлялись с 2010-х годов.
• Обсуждается, что в 2024 году Google Chrome полностью отключит поддержку HTTP, и это вызвало споры о том, насколько это нужно, учитывая, что большинство сайтов уже используют HTTPS.
• Участники обсуждают, что вместо того, чтобы отключать HTTP, Google мог бы вместо этого инвестировать в улучшение инструментов для разработчиков, чтобы они могли легче мигрировать с HTTP на HTTPS.
• Также обсуждается, что отключение HTTP может затруднить доступ к внутренним ресурсам в корпоративных сетях, где HTTPS не всегда практичен.

Исследователи безопасности обнаружили критическую уязвимость в системе Международной автомобильной федерации (FIA), позволившую получить несанкционированный доступ к персональным данным гонщиков Формулы-1. Через портал drivercategorisation.fia.com, используемый для присвоения гонщикам категорий, они смогли повысить свои привилегии до уровня администратора с помощью простого модифицированного HTTP PUT запроса, добавив параметр "roles" со значением "ADMIN".

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

• Сайт F1, который не смог защитить личные данные, был взломан, и это стало поводом для обсуждения, что компания, которая не может защитить данные, не должна быть доверена.
• Пользователи отметили, что сайт не только не защищает данные, но и не имеет bug bounty программы, что делает невозможным получить вознаграждение за найденные уязвимости.
• Некоторые участники обсуждения подчеркнули, что вместо того, чтобы устранять уязвимости, компания может начать угрожать исследователям, которые сообщают о проблеме.
• Было также отмечено, что вместо того, чтобы устранять уязвимости, компания может начать угрожать исследователям, которые сообщают о проблеме.

• Пользователи жалуются, что Postman и другие инструменты стали требовать онлайн-авторизацию и не работают оффлайн, что стало причиной перехода на альтернативы.
• Популярные альтернативы включают Insomnia, Bruno, Yaak и httpie, которые предлагают оффлайн-функциональность и не требуют входа в систему.
• Некоторые разработчики предпочитают использовать встроенные инструменты IDE, такие как VS Code REST Client или JetBrains HTTP Client, или просто curl.
• Обсуждение также коснулось того, что некоторые инструменты могут быть слишком сложными для простых задач, в то время как другие могут не хватать функциональности для более сложных сценариев.
• Некоторые участники упомянули, что выбор инструмента может зависеть от размера команды, сложности API и необходимости коллаборативной работы.

Новая функция http.CrossOriginProtection в Go 1.25 помогает защититься от CSRF, проверяя заголовки Sec-Fetch-Site и Origin. Она блокирует небезопасные запросы (POST, PUT и т.д.) от разных источников. Однако она не защищает от старых браузеров без этих заголовков. Для полной безопасности следует сочетать её с токенами.

• Обсуждение показало, что защита от CSRF через заголовки Origin/Sec-Fetch-Site работает примерно в 95% браузеров, и автор статьи не считает это проблемой.
• Участники обсуждали, что отказ от поддержки старых браузеров — это сознательный выбор, а не упущение, и что в 2025 году оставшиеся 5% в основном представляют собой старые телевизоры, телефоны и прочие устройства, которые не могут быть обновлены.
• Некоторые участники отметили, что даже если бы мы хотели защитить этих пользователей, устаревшие методы вроде проверки Referer или токенов всё ещё не защитят от CSRF, а значит всё равно придётся от них отказаться.
• Была поднята тема, что Rails и другие фреймворки уже давно решили эту проблему, но автор статьи ответил, что не видит в этом необходимости, так как считает, что вся ответственность за безопасность ложится на разработчика, который должен внимательно изучить документацию.

Автор перешёл с HTMX на Datastar, потому что последний убирает две проблемы: размер кода и сложность синхронизации фронтенда с бэкендом. Он показывает, что на практике это сокращает код на 60-70% и убирает необходимость вручную управлять состоянием на клиенте. Datastar заставляет сервер описывать, какие элементы и как должны обновляться, и это упрощает логику. Пример: вместо 3-4 атрибутов HTMX достаточно одного data-on-click. Это также убирает необходимость вручную следить за событиеми и состоянием, потому что вся логика находится в одном месте.

• Обсуждение в основном вращается вокруг сравнения Datastar и HTMX, где участники делятся опытом, спорят о том, какие фичи действительно нужны, и обсуждают, какие из фреймворков лучше подходят для разных сценариев использования.
• Несколько участников подчеркивают, что Datastar требует оплаты за ряд базовых функций, что вызывает сомнения в ценности продукта для open-source сообщества.
• Некоторые комментаторы высказывают, что Datastar и HTMX имеют разные подходы к обновлению контента: Datastar использует Server-Sent Events, в то время как HTMX использует обычные HTTP-запросы.
• Участники обсуждают, что Datastar требует больше кода на стороне сервера, в то время как HTMX позволяет легко обновлять различные части страницы без дополнительного кода.
• Некоторые комментаторы высказывают, что Datastar и HTMX имеют разные подходы к обновлению контента: Datastar использует Server-Sent Events, в то время как HTMX использует обычные HTTP-запросы.

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

Проект подчёркивает простоту и минимализм: сервер написан с акцентом на базовые функции, без избыточных зависимостей. Такой подход не только демонстрирует гибкость COBOL, но и вызывает интерес к его применению за пределами традиционных сфер.

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

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

Инструмент теперь полностью открыт под лицензией Apache 2.0 и включает интеграции с Kubernetes, MySQL, Git-совместимые рабочие пространства и возможности совместной работы в реальном времени. Планы развития включают удалённое выполнение, аудит, расширенные блоки и улучшенную интеграцию с облачными провайдерами.

• Пользователи отмечают полезность инструмента для документирования и выполнения команд, особенно для редких или сложных задач администрирования.
• Обсуждаются аналогичные подходы и инструменты: bash-скрипты, Jupyter Notebooks, org-mode в Emacs, runme.dev, speedrun.cc и Warp Notebooks.
• Поднимаются вопросы о безопасности, включая риски выполнения деструктивных команд из истории и необходимость подтверждения.
• Обсуждаются технические аспекты: поддержка shellcheck, формат файлов (YAML), работа с Git, удаленное и параллельное выполнение.
• Авторы отвечают на вопросы, подчеркивая гибкость подхода, планы по развитию и открытость к обратной связи.

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

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

• Обсуждается исторический контекст создания WWW как открытого и бесплатного протокола в эпоху доминирования подобных открытых стандартов (FTP, IRC, SMTP), что контрастирует с современными коммерческими «стенами».
• Высказывается мнение, что изначальная архитектура веба (клиент-сервер) не предусматривала защиту данных от монополизации и создания «закрытых садов», что привело к нынешней ситуации.
• Поднимается вопрос о рисках монополизации AI крупными корпорациями и выдвигается идея о необходимости международного некоммерческого подхода по образцу CERN.
• Участники спорят, был ли WWW очевидной идеей, ожидавшей реализации, или же гениальным и неочевидным изобретением, которое лишь кажется простым ретроспективно.
• Обсуждается противоречие между идеалами свободного веба и реальностью, где пользователи добровольно отдают данные ради удобства, а правительства и корпорации ограничивают открытость.

Это интерфейс онлайн-сервиса под названием «THE ROOM», предназначенного для совместного редактирования изображений. Пользователи могут загружать базовое изображение, настраивать количество шагов перед сбросом и добавлять промпты для изменений. Сервис предлагает несколько комнат для работы, включая основную и дополнительные. Перед началом требуется согласие с условиями использования и проверка на человечность. В ближайшем будущем ожидается появление пользовательских комнат.

• Проект вызвал большой интерес, но столкнулся с проблемами из-за перерасхода квот API (ошибки 429) и высокой нагрузки, что привело к временной недоступности.
• Пользователи отмечают ностальгическую атмосферу, сравнивая проект с "Million Dollar Homepage" и ранним интернетом, но многие опоздали и не смогли поучаствовать.
• Были предложены идеи по монетизации (плата за добавление объектов, использование собственных API-ключей) и технические улучшения для защиты оригинального контента от засорения.
• Основные жалобы: короткие очереди, быстрая заполняемость "комнат", отсутствие индикации очереди и возможность легко затереть оригинальное изображение.
• Создатель (@streetmeat) признал, что проект был "действительно хорошей плохой идеей", и благодарен за поддержку, но ограничен в ресурсах для расширения.

Открытый протокол x402 использует HTTP-статус 402 для мгновенных платежей через API без регистрации, OAuth или сложных подписей. Он бесплатен для обеих сторон, обеспечивает расчет за 2 секунды через блокчейн и не привязан к конкретной сети или токену. Для интеграции достаточно одной строки кода в middleware, что позволяет принимать платежи в USDC или других криптовалютах без прямого взаимодействия с блокчейном.

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

• Пользователи делятся опытом тестирования протокола x402, отмечая как простоту получения USDC и подключения кошелька, так и проблемы с потерянными транзакциями и потенциальной двойной оплатой.
• Критики указывают на скрытые комиссии блокчейна, волатильность сборов, корпоративный интерес Coinbase и отсутствие децентрализации по сравнению с Bitcoin и Lightning Network.
• Обсуждаются технические аспекты: использование HTTP 402, абстрагирование gas-фees, скорость подтверждений в блокчейне и сравнение с альтернативами (SEPA, L402, A2P).
• Высказываются опасения по поводу усложнения веб-платежей, пригодности для микроплатежей и опасности корпоративного захвата открытых платежных систем.
• Отмечается потенциал протокола для оплаты AI-агентами и API-запросов, но подчеркивается необходимость предоплаты и стандартизации для автоматизации.

Geofabrik обновила сервер для скачивания данных OpenStreetMap, сделав загрузки быстрее и доступнее. Теперь запросы на файлы с суффиксом «…latest» автоматически перенаправляются на актуальную версию через HTTP-редирект.

Однако сервер сталкивается с проблемами из-за нерационального использования: некоторые пользователи массово скачивают одни и те же большие файлы (например, 20-ГБ данные Италии тысячи раз за сутки), что замедляет работу для всех и вынуждает блокировать IP-адреса, затрагивая и невинных. Geofabrik призывает скачивать ответственно: использовать единый планшетный файл с planet.openstreetmap.org для глобальных данных, применять pyosmium-up-to-date для инкрементных обновлений крупных регионов (это экономит 98% трафика) и контролировать автоматизированные скрипты во избежание сбоев.

• Предлагается использовать BitTorrent или аналогичные P2P-технологии для распределения нагрузки при скачивании больших файлов, таких как данные OSM.
• Обсуждается необходимость внедрения базовых мер защиты: ограничение запросов (rate limiting), обязательная авторизация (API-ключи) для предотвращения злоупотреблений.
• Основная проблема — безответственное использование ресурсов, часто из-за ошибок в автоматизированных скриптах и CI/CD-пайплайнах, которые многократно загружают одни и те же файлы.
• Высказывается мнение, что часть пользователей не осознаёт последствий своих действий, и простые технические решения могли бы предотвратить проблему.
• Отмечается, что некоторые корпоративные среды блокируют P2P-трафик, что ограничивает применимость решений на основе BitTorrent.

Блог asciinema

• Начало работы
• Исследовать
• Форум
• Нанять меня!

3.0 Опубликовано 15 сен 2025, Марчин Кулик

Рад объявить о выпуске asciinema CLI 3.0!

Это полная переписывание asciinema на Rust с обновлением формата файлов записи, добавлением live-стриминга терминала и множеством улучшений.

В этом посте я расскажу о ключевых моментах релиза. Подробности смотрите в примечаниях к выпуску и истории изменений.

Переписывание на Rust было сделано из-за моего предпочтения этого языка перед Python для работы с системными вызовами и параллелизмом. Это привело к ускорению запуска, упрощению установки (статический бинарник) и интеграции виртуального терминала asciinema.

Формат файла asciicast v3

Новый формат asciicast v3 использует интервалы времени вместо абсолютных временных меток, что упрощает редактирование записей. Заголовок был реструктурирован, добавлена поддержка события выхода ("x") и комментариев через #.

Пример записи:

{"version": 3, "term": {"cols": 80, "rows": 24, "type": "xterm-256color"}, "timestamp": 1504467315, "title": "Demo", "env": {"SHELL": "/bin/zsh"}}
[0.248848, "o", "Hey Dougal...\n"]
[0.248848, "o", "Yes Ted?\n"]
[1.001376, "o", "Is there anything on your mind?\n"]
[3.500000, "m", ""]
[0.143733, "o", "No."]
[2.050000, "r", "90x30"]
[1.541828, "o", "Bye!"]
[0.8870, "x", "0"]

Формат уже поддерживается сервером и плеером asciinema.

Live-стриминг терминала

Новый CLI позволяет транслировать сессии терминала в реальном времени с двумя режимами:

• Локальный режим использует встроенный HTTP-сервер для просмотра в доверенных сетях
• Удаленный режим публикует поток через сервер asciinema с shareable URL

Примеры:

$ asciinema stream --local
::: Live streaming at http://127.0.0.1:37881

$ asciinema stream --remote  
::: Live streaming at https://asciinema.org/s/TQGS82DwiBS1bYAY

Плеер asciinema поддерживает адаптивную буферизацию для плавного воспроизведения. Сервер может записывать live-стримы, хотя на asciinema.org эта функция временно отключена.

Локальный приоритет

Ранние версии asciinema автоматически загружали записи на asciinema.org. Теперь CLI позволяет сохранять записи локально в файл формата asciicast v1 с выбором публикации или локального хранения.

• Участники высоко оценили Asciinema, особенно за простоту использования CLI, высокое качество GIF и новую функцию live-стриминга терминала.
• Было отмечено, что сервис, несмотря на высокую нагрузку, стабильно работает всего на двух маломощных виртуальных машинах (2 ГБ RAM каждая), что демонстрирует эффективность Elixir/Phoenix и BEAM.
• CLI-часть утилиты была переписана на Rust, что также было воспринято положительно.
• Некоторые пользователи выразили пожелания, такие как нативная поддержка экспорта в SVG/GIF и встроенные инструменты для скрытия секретов в записях.
• Обсуждались возможные сценарии использования live-стриминга, в том числе для стриминга программирования без дополнительного оборудования.

Размещение сайта на одноразовой вейп-системе

Примечание: эта статья НЕ размещена на сервере, работающем на одноразовой вейп-системе. Настоящий пример можно посмотреть здесь.

Предыстория

Я несколько лет собирал одноразовые вейпы у друзей и семьи, изначально извлекая из них батареи для «будущих» проектов. Современные устройства стали сложнее: с USB-C и перезаряжаемыми аккумуляторами. Во время разборки я обнаружил микроконтроллер с маркировкой «PUYA» — это оказался ARM Cortex-M0+.

Технические характеристики

Микроконтроллер PY32F002B имеет:

• 24 МГц Cortex-M0+
• 24 КБ флеш-памяти
• 3 КБ ОЗУ
• Минимальный набор периферии

Подключение к сети

Идея использовать вейп в качестве веб-сервера пришла после экспериментов с semihosting — системными вызовами для ARM через отладчик. Для передачи данных использовался протокол SLIP (Serial Line Internet Protocol), эмулирующий модемное соединение через последовательный порт.

Настройка в Linux:

pyocd gdb -S -O semihost_console_type=telnet -T $(PORT) $(PYOCDFLAGS) &
socat PTY,link=$(TTY),raw,echo=0 TCP:localhost:$(PORT),nodelay &
sudo slattach -L -p slip -s 115200 $(TTY) &
sudo ip addr add 192.168.190.1 peer 192.168.190.2/24 dev sl0
sudo ip link set mtu 1500 up dev sl0

Для реализации TCP/IP стека выбрана легковесная библиотека uIP, не требующая RTOS и поддерживающая базовый HTTP-сервер.

Вот краткое содержание обсуждения:

• Участники обсуждают китайские 4G-донглы и одноразовые вейпы как примеры невероятно дешевых, но мощных вычислительных устройств, которые содержат микроконтроллеры, память и даже GPS.
• Основная мысль: подобные устройства, будучи одноразовыми, представляют собой огромную проблему электронных отходов, и их статус «одноразовых» считается абсурдным и расточительным.
• Обсуждается технический парадокс: эти устройства обладают вычислительной мощью, о которой можно было только мечтать несколько десятилетий назад, но теперь они массово выбрасываются после одного использования.
• Многие пользователи восхищаются техническим достижением автора проекта (запуск веб-сервера на таком устройстве) и духом хакерства, но при этом испытывают смешанные чувства из-за контекста их применения.
• Поднимается вопрос о том, как законно утилизировать такие устройства (батареи и электронику), и выражается сомнение, что люди следуют этим правилам.
• В целом, текущее состояние технологий, где ИИ создает искусство, а веб-серверы работают на вейпах, характеризуется как «странное».

skiftOS
Включите JavaScript для работы приложения.

• За 6 лет автор SkiftOS написал микроядро, загрузчик, графическую оболочку, UI-фреймворк и даже движок браузера.
• Код на современном C++ (модули, async, co_await) и выглядит очень чисто; вдохновение Rust заметно.
• Система CPU-рендеринг, GPU — в планах; сеть пока только HTTP, без HTTPS.
• Безопасность: приложения не видят всю память и железо, драйверы в userspace, доступ по capability.
• Собрать можно под Linux/macOS (./skift.sh run --release <app>), но полный билд сейчас сломан.
• Автор признаёт: почти не было личной жизни, помощь была лишь с движком браузера.

oq — консольный просмотрщик OpenAPI-спецификаций.
Быстро открывает swagger.json|yaml в терминале, показывает эндпоинты, параметры, примеры ответов.
Установка: go install github.com/plutov/oq@latest.
Использование: oq spec.yaml.

• Утилита «oq» — терминальный просмотрщик OpenAPI-спецификаций, упрощающий навигацию по большим YAML/JSON.
• Пользователи практикуют spec-driven development: спецификация = единый источник правды, из неё генерируют типизированный клиент и сервер.
• Название «oq» уже занято другим проектом (homebrew-установка ставит не тот пакет); автор пока не переименовывает, предлагает брать бинарь с GitHub-релизов.
• Поддержка OpenAPI 3.1 заявлена, но реализована поверх библиотеки kin-openapi, которая 3.1 пока не умеет; для простого листинга маршрутов и компонентов это работает.
• В планах — добавить возможность делать реальные HTTP-запросы прямо из viewer.

• curl: 180 тыс. строк, 1,4 тыс. авторов, 20–25 активных в месяц, один зарплатный разработчик — сам Стенберг.
• Используют 47 брендов авто; спонсоров — 0.
• Компании требуют поддержку, аудиты, соответствие CRA, шлют угрозы «I will slaughter you».
• LLM-боты сыплют ложными баг-репортами, ИИ-скраперы ддосят сайт: 99,99 % трафика — боты.
• Поддержка = одному человеку: безопасность, документация, инфраструктура, иногда фичи.
• Письмо 11-летнего ребёнка — единственное тёплое «спасибо».

• Компании хотят платить за OSS, но бюрократия, налоги и отсутствие «адреса» делают это почти невозможным.
• Поток фейковых «AI-уязвимостей» превратился в охоту за CVE ради резюме и баг-баунти, отнимая время у maintainer’ов.
• curl получил 200 тыс. € от немецкого Sovereign Tech Agency — редкий пример гос-финансирования.
• Утопичная идея «AGPL-шантажа» и GoFundMe мгновенно оборачивается форком и потерей сообщества.
• Нет единого «клоут-индекса» библиотек: кто действительно критичен — видно только изнутри.

Как устроен 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.

Алгебраические эффекты на практике в Flix

Алгебраические эффекты — уже не академия. Это рабочий инструмент, который сегодня делает код:

1. Тестируемым — «что» отделено от «как»; mock-и и DI не нужны.
2. Прозрачным — сигнатура функции сразу показывает все побочные действия (IO, сеть, исключения).
3. Гибким — async/await, корутины, backtracking реализуются обычными библиотеками, без изменения языка.

В отличие от монад, эффекты понятны без теории категорий и работают «из коробки» в языке Flix.

---

Мотивирующий пример

Без эффектов:

def calculateSalary(base, percent) -> float:
    # может отправить письмо бабушке

С эффектами (Flix):

def calculateSalary(base: Float64, percent: Float64): Float64 \ {Email} =
    ...

Сигнатура не лжёт: любой вызов Email будет отслежен компилятором.

---

Обработчики эффектов (интуиция)

Эффект = операция + обработчик.
Код бросает операцию, обработчик решает, что с ней делать.

eff Ask {                     // объявляем эффект
    pub def ask(): String
}

def greet(): String \ Ask =   // используем
    "Hello " + Ask.ask()

def main(): Unit =            // обрабатываем
    println(greet() with Ask {
        def ask() = "World"
    })

---

Реальный проект: рекомендательная система фильмов

Задача: достать данные из SQLite, вызвать внешний AI-сервис, кешировать результат, логировать.

Эффекты: Db, Http, Log, Cache.

def recommend(user: String): List[Movie] \ {Db, Http, Log, Cache} = 
    Cache.getOrElse(user, 
        for {
            prefs <- Db.query(user)
            _     <- Log.info("Prefs loaded")
            recs  <- Http.post("ai.example.com", prefs)
            _     <- Log.info("AI answered")
            _     <- Cache.put(user, recs)
        } yield recs)

Тест: подменяем обработчики на in-memory реализации — никаких реальных запросов.

---

Куда дальше

• Попробовать онлайн: https://play.flix.dev
• Документация: https://doc.flix.dev
• Репозиторий: https://github.com/flix/flix

Flix ещё молод, но уже поддерживает эффекты, регионы, структурную конкурентность и Datalog.

• Участники восторгаются идеей алгебраических эффектов: они проще монад, решают «цветную» проблему функций и позволяют гибко компоновать побочные эффекты.
• Примеры уже есть: экспериментальная реализация в OCaml 5, библиотеки Effect и Effectively для TypeScript, языки Koka, Effekt, Unison.
• Отличие от ОО-интерфейсов: эффекты явно указывают контекстные требования (Net, IO) и позволяют подменять реализацию динамически, а не статически.
• Критика: система всё равно «окрашивает» код, требует прокидывать эффекты через весь стек вызовов и пока выглядит академично/громоздко.
• Практические вопросы: как скрыть «дебажный» вывод, не нарушая типов, и можно ли обойтись без переписывания сигнатур каждой промежуточной функции.

• HTML: справка по элементам, глобальным атрибутам, форматам дат/времени, руководства по адаптивным изображениям, видео и аудио.
• CSS: справка по свойствам, селекторам, @-правилам, единицам измерения; гайды по блочной модели, анимациям, Flexbox, цветам; «поваренная книга» для колонок, центрирования, карточек.
• JavaScript: справка по встроенным объектам, операторам, функциям; гайды по управлению потоком, циклам, объектам, классам.
• Web APIs: File System, Fetch, Geolocation, DOM, Push, Service Worker; гайды по Web Animations, Fetch, History, Speech API, Web Workers.
• Другие технологии: Accessibility, HTTP, URI, WebAssembly, WebDriver, WebExtensions.
• Обучение: курс «Frontend-разработчик», основы HTML, CSS, JavaScript.
• Инструменты: Playground, HTTP Observatory, генераторы теней, радиусов, границ, палитра цветов.

• Участники обсуждают, как использовать тег <template> без фреймворков: он удобен для клонирования больших фрагментов, ускоряет рендер и снижает нагрузку по сравнению с React/Vue.
• Недостаток — приходится вручную связывать данные и DOM; многие хотят единого формата «HTML+CSS+JS» для компонентов.
• Shopify, Salesforce, MedusaJS и Alpine.js уже применяют <template> в продакшене, но спецификация HTML Modules пока не завершена.

xv6-riscv-net
Форк MIT xv6 для RISC-V с добавлением стека TCP/IP.
Поддерживаются драйвер RTL8139, DHCP, DNS, ping, telnet-сервер, HTTP-клиент.

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

make qemu

Внутри QEMU:

$ dhcp
$ ping 8.8.8.8
$ telnetd &
$ http google.com

Сетевые утилиты

• dhcp – получить адрес
• ping – проверка связи
• telnetd – сервер на порту 23
• http – простой HTTP-клиент

Код

• kernel/net* – стек TCP/IP
• kernel/rtl8139.c – драйвер сетевой карты
• user/{dhcp.c,ping.c,telnetd.c,http.c} – сетевые утилиты

• @Tony_Delco и @dancek восхищаются сложностью и качеством реализации TCP/IP-стека для xv6 с virtio-net и сокетами, подчеркивая, что это «золото» для любителей low-level.
• @AbbeFaria сообщает, что проходит лабораторные xv6 и сейчас занят mmap и fork.
• @lesser-shadow интересуется, используются ли RISC-V-расширения и возможностью запуска на bare metal.
• Все участники благодарят автора за открытость и делятся вдохновением.

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, отмечая, что нужен более дружелюбный аналог.

Краткое руководство по хорошему API-дизайну

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

Не ломаем userspace

• Добавлять поля можно.
• Удалять, менять тип или структуру полей — нельзя.
• Даже опечатка в HTTP-заголовке referer навсегда останется опечаткой, потому что «мы не ломаем userspace».

Как изменять API без боли

Если изменение критично, используйте версионирование:

• Параллельно запускаем старую (/v1/) и новую (/v2/) версии.
• Сообщаем клиентам, ждём месяцы или годы, затем выключаем старую.
• Stripe и OpenAI делают именно так, но это всё равно «зло из необходимости»: путает пользователей и усложняет поддержку.

Итог: проектируйте API так, чтобы не пришлось его трогать.

• «Никогда не ломать userspace» — про стабильность обещанного интерфейса; внутренние kernel-API могут меняться без предупреждения.
• Версионирование спорно: кто-то советует закладывать /v1 сразу, кто-то — избегать /v2, чтобы не плодить долгую поддержку.
• Идемпотентность считается обязательной: ключ лучше хранить в той же транзакции, что и мутация, а не в Redis.
• Cursor-пагинация удобнее offset: не повторяет элементы при добавлении новых данных.
• «API» — это не только HTTP/JSON, но и любой программный интерфейс; термин стал слишком узким в веб-контексте.

Кратко: плагин nvim-web-server на чистом Lua отдаёт HTTP-запросы прямо из открытых буферов Neovim, без внешних зависимостей, с нативной поддержкой Djot и быстрее Nginx.

Почему так быстро?

• Однозадачность: только статика.
• libuv + асинхронный I/O Neovim.
• LuaJIT: NaN-тегинг, отсутствие boxing чисел, allocation sinking.
• aiohttp тормозит из-за парсера на чистом Python и boxing в CPython.

Бенчмарк, RPS (среднее):

сервер	1	50	100	200	400
nvim-web-server	3981	15284	15124	14476	14446
Nginx	4451	11306	11576	10011	10461
aiohttp	6391	8477	8448	7696	7132

Развёртывание: живёт на старом ThinkPad, 9 буферов — весь сайт.

Безопасность: да, но мелочи мы игнорируем.

• Пользователи в восторге от статьи: называют её «одной из любимейших» и приводят цитату «они были так заняты тем, могут ли, что не спросили себя, стоит ли».
• Кто-то отмечает, что сайт резолвится на IP Linode, но не объясняется, зачем нужен промежуточный сервер.
• Обсуждают безопасность: пример показывает, что «никогда не бывает так, чтобы код точно не запустили по сети».
• Некоторые шутят, что Neovim теперь можно считать кроссплатформенным рантаймом «ужаса», но признают крутость эксперимента.
• Предполагают, что высокая скорость может быть из-за хранения файлов в RAM, а не на диске, и что всё равно всё закешируется.

StarDict — кроссплатформенный словарь GPLv3 — при работе в X11 по умолчанию пересылает выделенный пользователем текст по нешифрованному HTTP на два китайских сервиса: YouDao и dict.cn.

Проблема обнаружена Винсентом Лефевром 4 августа 2025 года при подготовке к Debian 13. Пакет stardict-plugin, который ставится автоматически, содержит плагин YouDao. Функция «scan» (включена по умолчанию) отслеживает выделение мышью и отправляет текст на серверы без шифрования.

На Wayland уязвимости нет: система блокирует чтение чужих выделений, но и «scan» не работает.

Сопровождающий Debian Сяо Шэн Вэнь считает поведение допустимым: функции можно отключить. Лефевр возражает: конфиденциальные возможности не должны быть активны по умолчанию.

Описание пакета упоминает «scan», но не говорит, что YouDao — онлайн-сервис. Сяо предложил вынести сетевые плагины в отдельный пакет, но сомневается в необходимости.

Аналогичные проблемы сообщались в 2009 и 2015 годах; тогда отключили сетевые словари по умолчанию, но плагин YouDao (добавлен в 2016) игнорирует эту настройку.

• Пакет StarDict по умолчанию отправляет выделенный текст на китайские серверы по нешифрованному HTTP.
• Мейнтейнер Debian отмахнулся: «в описании пакета всё написано, RTFM».
• Пользователи возмущены: словарь можно было сделать полностью локальным (≈ 400 МБ), а поведение — опциональным.
• Уязвимость годами игнорировалась, баг-репорты закрывались как «небаг».
• Сообщество требует исключить StarDict из репозиториев и пересмотреть политику мейнтейнеров.

• Проект ch.at — это минималистичный «чат» через DNS/HTTP, позволяющий общаться с LLM без JS и даже на самолёте без оплаченного Wi-Fi.
• Автор удивлён популярностью: сервис почти не стоит денег, пока не нужен rate-limit, а домен ch.at куплен за ≈ $50k как удачный «домен-хак».
• Пользователи уже сделали обвязки под i3-dmenu, Raycast, shell-алиасы и даже используют dig TXT +short.
• В комментариях обсуждают отсутствие IRC/XMPP/SIP, перспективу более дешёвых локальных моделей, политику логов и защиту от DDoS.

MCP игнорирует 40 лет опыта RPC и обрекает компании на сбои

Проблема
Model Context Protocol (MCP) позиционируется как «USB-C для ИИ», но жертвует надежностью ради простоты. Компании внедряют его в продакшен, не осознавая, что в основе лежит архитектура без базовых механизмов, которые считаются обязательными в RPC-системах с 1982 г.

4 пропущенных урока

1. Типы данных
   UNIX RPC (1982) ввёл XDR и IDL, чтобы 32-битное целое не превратилось в мусор на другой архитектуре. MCP использует схематичный JSON: проверка типов происходит в рантайме, если вообще происходит. В результате ИИ-трейдер может ошибиться в десятичном разряде, а медицинский ассистент — перепутать дозировку.

2. Кросс-языковая совместимость
   CORBA (1991) генерировала привязки под C++, Java, Python и т. д., гарантируя, что исключение на сервере корректно обработается клиентом. MCP оставляет реализацию на усмотрение каждого языка: Python и JavaScript по-разному кодируют Unicode и float, что ведёт к тихим ошибкам интеграции.

3. Безопасность и версионирование
   gRPC и SOAP научились:

   • TLS/mTLS по умолчанию
   • строгая обратная совместимость через IDL
   • единое управление ошибками и таймаутами
     MCP не требует шифрования, не описывает, как менять контракт, и не стандартизирует retry-логику. Каждый инструмент решает сам, как сообщать об ошибке.

4. Масштабирование и наблюдаемость
   Современные RPC-фреймворки включают распределённый трейсинг, rate-limiting, circuit breaker. MCP не предоставляет ни метрик, ни механизмов отказоустойчивости. При миллионах вызовов в день компании получают «чёрный ящик», который нельзя отладить и который падает при первой же нагрузке.

Итог
Простота MCP полезна для прототипов, но в продакшене превращается в долговременный техдолг. Пока MCP не добавит IDL, строгие типы, безопасность и наблюдаемость, внедрять его в критичных системах — значит повторять ошибки, которые отрасль исправляла последние 40 лет.

• Критики считают MCP «USB-C для ИИ»: универсальным, но с расплывчатыми стандартами и слабой типизацией.
• Сторонники отвечают: именно минимализм JSON-over-HTTP обеспечил быструю массовую adoption, в отличие от громоздких SOAP/CORBA.
• Спор о схемах: MCP поддерживает JSON Schema, но валидация не обязательна, поэтому ошибки типов всплывают только в рантайме.
• Поднимаются темы безопасности и трейсинга: нет встроенного аудита вызовов и расходов, что критично для enterprise.
• Общий вывод: MCP сейчас «хорошо достаточно» для веба, но для регулируемых или высоконагруженных сред потребуется или доработка, или новая спецификация.

OpenFreeMap выдержал 100 000 запросов/с

Внезапно сервис получил 3 млрд запросов за сутки и 215 ТБ трафика.
Пиковая нагрузка — 100 000 rps.
Стоимость такого трафика у конкурентов превысила бы $6 млн/мес.

Единственный замеченный сбой — nginx жаловался на «слишком много открытых файлов», но 96 % запросов успешно обслужены (200 OK), лишь 3,6 % вернули 206 Partial Content.
Система продолжала работать, Cloudflare кешировал даже «пустые» тайлы.

Причина всплеска — новый коллаборативный сайт рисования wplace.live, построенный на OpenFreeMap и ставший вирусным.

• На фоне внезапного хайпа wplace.live (2 млн пользователей, 3 млрд запросов) бесплатный OpenFreeMap получил «объятие смерти» ~1 000 rps, что выявило узкое место в лимите открытых файлов nginx.
• Автор OFM защитил решение ограничить по Referrer и отказаться от IP-рейт-лимита, чтобы не блочить обычных пользователей.
• Часть комментаторов считает, что бесплатный сервис не обязан выдерживать такую нагрузку; другие спорят, кто виноват — отсутствие лимитов или неожиданный виральный проект.
• Обсуждаются альтернативы: Cloudflare-only хостинг, PMTiles-файлы, self-host, но все сходятся, что 96 % доступности при таком наплыве — уже успех.