• Пользователи высоко оценили GPT-5-Codex за умение работать с длинным контекстом, качественное исследование кода и завершение задач без "бросания на полпути", в отличие от Gemini и Claude Code.
• Основные жалобы на Codex касаются нестабильности сервиса (частые простои), высокой скорости расходования кредитов и автоматического списания средств при превышении лимита плана Pro.
• Многие сравнивают Codex с Claude Code, отмечая, что после обновления Codex стал значительно эффективнее, особенно в рефакторинге, хотя иногда может проявлять "лень" и требовать подтверждения для продолжения сложных задач.
• Обсуждается проблема несоответствия форматирования (Codex использует пробелы вместо табов) и отсутствие поддержки пользовательских контейнеров.
• Новая модель GPT-5-Codex, оптимизированная для кодинга, стала доступна в CLI и облачных продуктах OpenAI, но пока не в API; она обещает улучшенный код-ревью и возможность работать до 7 часов.
• Некоторые пользователи столкнулись с замедленной работой модели и проблемами скорости, не видя существенной разницы между режимами medium и high.
• Важным фактором для многих остается конфиденциальность, и в этом отношении Cursor с его "режимом приватности" сохраняет преимущество перед Codex.
• В обсуждении упоминается добавление поддержки MCP (Model Context Protocol) и необходимость ручного обновления CLI через NPM для доступа к новым функциям.
• Отмечается, что JetBrains с бэкендом на GPT-5 предлагает подписку за $30/мес, но квоты сгорают очень быстро, что вызывает вопросы о долгосрочной ценовой политике OpenAI.

В C# 14 появились операторы условного присваивания для null, которые позволяют безопасно присваивать значения свойствам или индексаторам без бесконечных проверок if.

Если вы работали с C#, вам знаком код вроде:

if (config?.Settings is not null) 
{
    config.Settings.RetryPolicy = new ExponentialBackoffRetryPolicy();
}

Теперь это можно записать одной строкой:

config?.Settings?.RetryPolicy = new ExponentialBackoffRetryPolicy();

Новые операторы работают как с обычными присваиваниями, так и с составными (+=, -=), а также могут комбинироваться с оператором объединения с null (??=):

customer?.Name ??= "Guest";

Важно помнить: если левая часть выражения равна null, правая часть не выполняется, что предотвращает побочные эффекты.

• Введение оператора ?. для присваивания (a?["b"] = c) как логическое завершение существующей функциональности null-conditional операторов, повышающее консистентность языка.
• Критика нового синтаксиса как избыточного, усложняющего язык и маскирующего проблемы дизайна данных, приводящие к глубоким цепочкам проверок на null.
• Опасения по поводу снижения читаемости и удобства отладки из-за скрытого поведения (пропуск присваивания при null) и потенциального чрезмерного использования.
• Поддержка функции как способа сократить шаблонный код и сделать его менее многословным, аналогично реализациям в Swift, Kotlin и Ruby.
• Споры о том, следует ли языку C# продолжать агрессивно добавлять новые функции, рискуя стать перегруженным и менее доступным, как C++.
• Замечание, что данное изменение не добавляет новой семантики, а лишь расширяет существующий синтаксис, завершая его реализацию.
• Упоминание, что более востребованные функции (например, discriminated unions) разрабатываются отдельно и их появление не связано с этим изменением.

Хостинг сайта на одноразовой вейп-системе

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

Предыстория

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

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

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

• 24 МГц Cortex-M0+
• 24 КБ флеш-памяти
• 3 КБ оперативной памяти
• Несколько периферийных устройств (не использовались)

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

Идея использовать вейп как веб-сервер пришла после экспериментов с semihosting — системными вызовами для embedded-микроконтроллеров.

Для связи использовался протокол SLIP (Serial Line Internet Protocol), эмулирующий модемное соединение через последовательный порт. С помощью pyOCD и socat создаётся виртуальный tty-интерфейс:

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 и легко портируемый на другие платформы.

• Обсуждается использование дешёвых и мощных китайских LTE-донглов и одноразовых вейпов (например, с чипом Qualcomm MSM8916) в качестве мини-компьютеров для нестандартных задач, включая хостинг веб-сервера.
• Участники выражают возмущение расточительством и экологическим ущербом от одноразовых вейпов, содержащих полноценные микроконтроллеры, перезаряжаемые батареи и иногда даже цветные дисплеи или Bluetooth.
• Подчёркивается технологический парадокс: устройства с вычислительной мощностью, превосходящей старые компьютеры (например, Commodore 64), становятся одноразовыми и массово выбрасываются.
• Отмечается юридический и этический аспект: классификация устройств с USB-C и аккумулятором как "одноразовых" вызывает вопросы, особенно в регионах с запретом на подобные изделия.
• Хакерский проект по запуску веб-сервера на вейпе воспринят как креативный и вдохновляющий пример вторичного использования электроники, характерный для духа Hacker News.
• Обсуждаются технические детали реализации: использование SLIP/PPP, Perl, nginx для балансировки нагрузки, а также шуточные предложения вроде запуска Doom или облачного хостинга ("vaperware").
• Упоминается проблема утилизации: несмотря на законодательные ограничения в ЕС, устройства часто выбрасываются с обычным мусором, что усугубляет проблему электронных отходов.
• Участники шутят о "объятиях смерти" от трафика Hacker News (ошибка 503) и предлагают идеи для повторного применения устройств (например, автоматические кормушки для животных).
• Поднимается вопрос о целесообразности столь мощных ядер (Cortex-M0) в одноразовых устройствах и дешевизне их производства, что делает их доступными для экспериментов.

React победил по умолчанию — и это убивает фронтенд-инновации

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

Команды редко начинают с вопроса «Какие ограничения и какой инструмент подходит лучше?». Чаще звучит: «Давайте использовать React — все его знают». Это создаёт цикл, где архитектуру определяют сетевые эффекты, а не техническая целесообразность.

Между тем, фреймворки с реальными инновациями борются за внедрение. Svelte устраняет накладные расходы компиляцией, Solid предлагает детальную реактивность без виртуального DOM, Qwik обеспечивает мгновенный запуск через возобновляемость. Эти подходы часто превосходят модель React, но редко получают оценку, потому что React выбирают по умолчанию.

Проблема не в самом React, а в мышлении «React по умолчанию».

Потолок инноваций

Технические основы React объясняют современные трудности. Виртуальный DOM был умным решением для проблем 2013 года, но, как отметил Рич Харрис, он вводит издержки, которых можно избежать с помощью компиляторов.

Хуки решили проблемы классовых компонентов, но добавили сложности: массивы зависимостей, устаревшие замыкания, неправильное использование эффектов. Даже документация React призывает к сдерженности: «Вам может не понадобиться эффект». Серверные компоненты улучшают время до первого байта, но добавляют архитектурную сложность.

Компилятор React — умное решение для автоматизации useMemo/useCallback, но его существование сигнализирует: мы оптимизируем вокруг ограничений модели.

Альтернативы предлагают иные подходы: Runes в Svelte 5 упрощают реактивность на этапе компиляции, детальная реактивность Solid обновляет только изменённые части, возобновляемость Qwik устраняет традиционную гидратацию. Это не инкрементные улучшения React, а другие модели с иными пределами.

Инновации без внедрения не меняют результаты. Внедрение невозможно, когда выбор делается рефлекторно.

Технический долг, который мы несём

Выбор React по умолчанию часто означает runtime и затраты на согласование, которые мы больше не questioned. Даже когда он достаточно быстр, его потолок ниже, чем у моделей с компиляцией или детальной реактивностью. Время разработчиков тратится на управление перерисовками, зависимостями эффектов и границами гидратации вместо создания ценности.

Исследования производительности единодушны: JavaScript дорог на критическом пути.

Мы сосредоточили ментальные модели вокруг «React-паттернов» вместо основ веба, снижая переносимость навыков и увеличивая архитектурную инерцию.

Потеря не только в производительности, но и в упущенных возможностях, когда альтернативы не оцениваются. Например, бенчмарки показывают, что Solid в 2-3 раза быстрее React в сценариях с интенсивной реактивностью.

Фреймворки, которым не дают развиваться

Svelte: революция компилятора

Svelte переносит работу на этап компиляции: нет виртуального DOM, минимальный runtime. Компоненты становятся целевыми операциями DOM. Ментальная модель соответствует основам веба.

Но «недостаточно вакансий» искусственно сдерживает внедрение Svelte, несмотря на технические преимущества.

• React побеждает благодаря композиции функций JavaScript, интуитивной модели и стабильности, а не только из-за сетевых эффектов.
• Веб-компоненты рассматриваются как путь к совместимости между фреймворками и снижению зависимости от экосистемы React.
• Многие разработчики ценят React за предсказуемость, лёгкость найма и богатую экосистему, что делает его безопасным выбором.
• Критики указывают на сложности React (хуки, зависимости, ререндеры) и чрезмерный boilerplate-код.
• Альтернативы вроде Svelte или Solid предлагают упрощённые модели и лучшую производительность, но проигрывают в распространённости.
• Инновации во фронтенде часто воспринимаются как «суета», ведущая к устареванию проектов и постоянным переписываниям.
• React доминирует частично из-за React Native, что позволяет использовать единую кодобазу для web и мобильных платформ.
• Браузеры и стандарты Web обвиняются в недостаточной скорости развития, что вынуждает полагаться на фреймворки.
• Стабильность и стандартизация ценятся выше постоянных изменений и «инноваций» в индустрии.

macOS Tahoe

Свежий вид.

Вечно Mac.

macOS Tahoe представляет новый дизайн Liquid Glass — красивый, приятный и мгновенно узнаваемый.

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

• Liquid Glass — новый дизайн с прозрачными элементами и динамическими эффектами.
• Приложение "Телефон" — теперь на Mac с поддержкой Live Activities для улучшенной интеграции с iPhone.
• Spotlight — выполняйте сотни действий, не отрывая рук от клавиатуры.
• Умные сокращения — создавайте мощные сценарии с помощью Apple Intelligence.

Дизайн

macOS Tahoe переосмыслен с помощью Liquid Glass, сочетающего свежесть и узнаваемость. Приложения фокусируются на контенте, а персонализация Mac выходит на новый уровень.

• Новый дизайн — Liquid Glass отражает контент в реальном времени, добавляя ясности навигации и элементам управления.
• Обновлённые иконки — персонализируйте Mac с новыми вариантами оформления, включая светлые и тёмные темы, цветные иконки или прозрачный стиль.
• Персонализированные элементы — прозрачная строка меню и расширенные возможности настройки Control Center, включая сторонние приложения.

• Пользователи крайне негативно оценили новый дизайн Liquid Glass в macOS Tahoe, называя его уродливым, непрофессиональным и похожим на дешёвую Android-тему или игрушку.
• Ключевые претензии к интерфейсу: чрезмерно скруглённые углы окон, избыточные отступы (padding), потеря плотности информации, прозрачность, ухудшающая читаемость, и визуальная несогласованность элементов.
• Многие отмечают большое количество багов, неисправленых с бета-версий, и общее ощущение незавершённости и низкого качества релиза.
• Обновление критикуют за ухудшение юзабилити и производительности (например, лагающий запускатель приложений), а также за игнорирование потребностей людей с ограниченными возможностями.
• Некоторые пользователи впервые решили пропустить мажорное обновление macOS и остаться на предыдущей версии или перейти на Linux (KDE), который хвалят за функциональность и стабильность.
• Есть единичные положительные отзывы о новой стилистике, большей «персонализации» и улучшенной производительности в iOS 26, но они тонут в общей массе критики.
• Пользователи отмечают, что Apple отошла от своих прежних принципов дизайна (доступность, ясность, функциональность) в угоду моде.
• Под сомнение ставится сама целесообразность встраивания генерации AI-изображений в операционную систему как её основная функция.
• Общий совет от опытных пользователей — не обновляться до версии x.1 или x.2, чтобы дождаться исправления ошибок и улучшения стабильности.

• Новый GPT-5-Codex имеет вдвое меньший размер промпта (10 КБ против 23 КБ) и демонстрирует схожую с GPT-5 производительность на SWE-bench, но значительно лучше справляется с рефакторингом (51.3% против 33.9%).
• Пользователи отмечают резкое улучшение качества Codex CLI по сравнению с предыдущими версиями и конкурентом Claude Code, который, по их мнению, стал хуже и имеет более низкие лимиты использования.
• Многие пользователи переходят с Claude Code на Codex, мотивируя это большей скоростью, щедрыми лимитами использования, включенными в подписку ChatGPT Pro, и меньшей склонностью модели к "фейковым" решениям.
• Ключевые улучшения UX: модель стала надежнее использовать интерфейс выполнения задач (Task Completion), лучше комментирует код при ревью и генерирует меньше лишних токенов для простых задач.
• Некоторые пользователи сталкиваются с проблемами: крайне низкая скорость работы модели в первые дни после релиза, сложности с установкой (npm-ошибки) и отсутствие режима, аналогичного "normal mode" в Claude.
• Появилась интеграция Codex CLI с планом подписки ChatGPT (около месяца назад), что делает его более доступным, однако поддержки API для GPT-5-Codex пока нет, но обещана в будущем.
• Обсуждаются workflow-проблемы: отсутствие промежуточного режима между полной автономией и ручным копированием, плохая обработка перемещения файлов, необходимость вручную одобрять опасные команды.
• Конкуренция смещается с raw-качества моделей на качество интеграции в IDE и workflow (терминал, GitHub, мобильное приложение), создавая эффект lock-in.
• Пользователи рекомендуют стратегию работы: сначала заставлять модель составлять план и утверждать его, а лишь потом приступать к реализации, чтобы избежать нежелательных действий.

Хотел следить за собакой, а следил за TP-Link

Купил дешёвую камеру Tapo, чтобы наблюдать за собакой в своё отсутствие. В итоге пришлось реверсить процесс подключения, декомпилировать APK, перехватывать TLS-трафик и писать криптографические скрипты.

Камера раздражала с первого дня: настройка в frigate оказалась сложной, а информации в сети почти не было.

Примечание: для двустороннего аудио в frigate используйте tapo:// вместо rtsp://. TP-Link ленивы и реализовали аудио только в своём API.

Выяснилось, что после подключения устройство ожидает логин admin и пароль от облака Tapo. Но если сменить пароль в облаке, устройства об этом не узнают. Это навело на мысли:

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

Раздражение из-за навязчивых подписок в приложении Tapo подтолкнуло к поиску облачного решения для подключения.

Перехват трафика

Для перехвата трафика мобильного приложения нужно направить весь HTTP(S)-трафик через прокси. Современные приложения игнорируют прокси и используют привязку сертификатов. Надёжный метод — динамическая инструментация через frida, которая заставляет приложение использовать нужные прокси и сертификаты.

Схема перехвата:

Приложение Tapo (с frida) -> Ноутбук (mitmproxy) -> Камера Tapo

После запуска mitmproxy и внедрения скриптов frida удалось увидеть первоначальный логин до смены пароля:

{
  "method": "login",
  "params": {
    "cnonce": "AD0E189F6E1BA335",
    "encrypt_type": "3",
    "username": "admin"
  }
}

Последующие запросы были зашифрованы:

{
  "method": "securePassthrough",
  "params": {
    "request": "bAhdgihJ9j6PrrknnbXWATBohGTZK5llv3MEzRcmoAmcxexmlVNz3OUX2r0h9a9EG/3X0tBpPi654T2+BjqVEOn2D178kokBpf8RQj01AvBZLYD5S5sFeaCXWiRXA7MgQUppROV4AbrU4f+GOM37KgPqT59qgLVja2slw6CzrKjPzOrG4Ho6Mu6wBa1xepcj"
  }
}

Выводы:

• У Tapo есть пароль по умолчанию, так как логин происходит до знания облачного пароля.
• API использует зашифрованный канал securePassthrough.

Декомпиляция APK

Следующий шаг — декомпиляция APK в JADX для поиска пароля по умолчанию. Запрос логина содержит имя пользователя admin. Поиск по коду привёл к классу CameraOnboardingViewModel, где функция возвращала пароль, передаваемый в new Account().

Пароль по умолчанию для encrypt_type: 3: TPL075526460603

Анализ трафика

С паролем по умолчанию можно получать ключи сессии и расшифровывать сообщения securePassthrough. Для анализа процесса аутентификации пригодилась библиотека PyTapo. С её помощью можно было декодировать запросы из mitmproxy и провести статический анализ.

• Использование Frida-скриптов для перехвата трафика и обхода проверки сертификатов в Android-приложении Tapo для получения пароля от камеры
• Обход ограничений TP-Link: для двустороннего аудио необходимо использовать проприетарный протокол tapo:// в go2rtc, но это лишает возможности использовать ONVIF для управления поворотом камеры
• Критика безопасности IoT и потребительских роутеров: прошивки часто не обновляются годами, содержат уязвимости (CVE), пользователи редко меняют пароли по умолчанию
• Предложение выбирать устройства, изначально поддерживающие открытые стандарты (например, RTSP) и не требующие обязательного использования облачного сервиса и мобильного приложения
• Обсуждение последствий будущих ограничений Android (требование подписи приложений) для реверс-инжиниринга: на рутованных устройствах и эмуляторах методы останутся работоспособными
• Упомянуты полезные инструменты и проекты: HTTP Toolkit, go2rtc для совместимости с разными потоками, библиотека PyTapo для работы с камерами Tapo
• Найдены и использованы уязвимости (CVE-2022-37255) с хардкодными паролями, которые пользователь должен сменить при первоначальной настройке
• Разочарование в IoT-устройствах, требующих обратного инжиниринга для базового функционала; снижение энтузиазма к такому взлому
• Проблема отсутствия URL для получения статичного снимка (snapshot) с камер Tapo и необходимость использовать FFmpeg для извлечения кадра из видеопотока

• Bambu P1S/X1C рекомендуют за надежность, скорость и простоту использования, но критикуют за закрытость и практики компании.
• Voron или RatRig предлагают как полностью открытые и ремонтопригодные варианты для сборки и кастомизации.
• Prusa Core One отмечают за хорошую поддержку и открытость ПО, но не всегда за аппаратную часть.
• Sovol SV08 и Elegoo Centuri Carbon рассматривают как бюджетные альтернативы с большим объемом сборки и функциями.
• Qidi хвалят за баланс между надежностью и возможностью тюнинга, а также за работу с инженерными материалами.
• Creality K1/K1 Max предлагают как быстрые и хорошо оснащенные принтеры по доступной цене.
• Некоторые советуют начать с недорогого б/у принтера для обучения или вовсе использовать сервисы печати на заказ.

Microsoft начнёт принудительную установку приложения Microsoft 365 Copilot в октябре для пользователей коммерческих версий Microsoft 365. Это коснётся устройств под управлением Windows в управляемых средах.

Приложение будет автоматически устанавливаться через Microsoft Edge, но не будет добавлять значки на рабочий стол или в меню "Пуск". Пользователи смогут удалить его через стандартные средства Windows.

Microsoft заявляет, что Copilot поможет повысить продуктивность за счёт интеграции с Microsoft 365, но критики выражают обеспокоенность из-за принудительной установки.

• Пользователи критикуют Windows за перегруженный интерфейс, низкую производительность и навязывание нежелательных функций, таких как Copilot и Recall.
• Многие выражают разочарование политикой Microsoft, которая, по их мнению, превращает ОС в инструмент для продвижения подписок и облачных сервисов в ущерб интересам пользователей.
• Отмечается, что Copilot часто устанавливается без явного согласия, а его отключение требует нетривиальных действий через редактор групповых политик.
• В связи с этим растёт интерес к переходу на Linux, особенно благодаря Proton/Steam, хотя сохраняются проблемы с поддержкой некоторых игр и софта.
• Пользователи из ЕС отмечают, что регулирование защищает их от навязчивого обновления, и выражают надежду на распространение подобной практики.

Блог 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-стриминга, в том числе для стриминга программирования без дополнительного оборудования.