Голосовой ввод для Windows за ~1 секунду | Полностью локально • CPU • Open Source
Как заставить Whisper распознавать речь почти в 4 раза быстрее на обычном CPU без GPU и без облака. Разбираю архитектуру WhisperType, сужение окна энкодера, потоковую обработку аудио, оптимизацию faster-whisper и подводные камни WinAPI.
Я диктую постоянно: сообщения, заметки, постановку задач — говорить в разы быстрее, чем печатать, а мысль не успевает остыть. Проблема в том, что удобной диктовки, которая не гонит звук в чужое облако, я не нашёл. Так появился PasteTalk: локальная диктовка для Windows по горячей клавише, а вокруг неё — собственный сервер, приложение для телефона и Telegram-бот.
Отдельным требованием стала мама: из-за слабого зрения печатать на телефоне она почти не может, и телефонная часть проектировалась под самый жёсткий случай — одна кнопка на весь экран, крупный шрифт, ошибки словами. Забегая вперёд: правки «для мамы» сделали приложение удобнее и для всех остальных.
Под катом — архитектура, цифры и четыре бага, каждый из которых молча съедал наговорённый текст.
Я делаю NotiBox — Pusher‑совместимый сервис realtime уведомлений. Под капотом я использую Sockudo — WebSocket сервер на Rust. Прежде чем показывать реальным пользователям, я решил проверить, на сколько Sockudo на самом деле «blazingly fast».
Я ожидал, что это будет лёгкая прогулка, типичное тестирование нагрузки. Даёшь мало ресурсов серверу, запускаешь бенчмарк, видишь что он захлёбывается запросами в какой‑то момент, и фиксируешь показатели.
Идеальный сценарий — полная загрузка процессора, памяти или сети, тогда ты реально нашёл предел ресурсов. Проверяешь масштабируемость и готово.
Другой сценарий — ничего не перегружено, но новые соединения/запросы не проходят, растёт задержка ответов. Это тоже ожидаемо и понятно как чинить: смотришь на TIME WAIT сокеты, max open files, и другие «предохранители».
А что делать, если там тоже всё по нулям? Вот тут начинается настоящее приключение.
Есть на GitHub репозиторий из одного файла: 9 коммитов, 48 звёзд, лицензия GPL-2.0. Через него проходит заметная часть всех станков, где LinuxCNC разговаривает с сервоприводами по EtherCAT, — и у него нет ни форков, ни конкурентов, ни «переписал на Rust». Когда мы начинали свой стенд, это казалось странным; спустя месяцы наладки трёх серво по живой шине ответ нашёлся — и он интереснее, чем «проект заброшен». Под катом — весь стек от сетевой карты до joint.0.motor-pos-cmd и шесть граблей, которых нет ни в одном README: карта битов, съехавшая на +4 против мануала, SDO-записи навсегда в EEPROM и момент −0.4%, показанный как 6553%.
Меня зовут Артур Валиев. Я открыл исходники EvertyDesk Lite — и заодно EvertyDesk Next, то, что должно было стать следующей версией. Полностью. Без купюр.
Что произойдет, если большая языковая модель (LLM) добавит в код пакет, которого никогда не существовало? Разработчик может принять рекомендацию за корректную, а злоумышленник – опубликовать под придуманным именем вредоносный пакет. Тогда ошибка модели превращается в возможность атаки на цепочку поставки.
Перед вами обзор исследования We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs. Авторы проверили 16 моделей, сгенерировали 576 000 образцов кода на Python и JavaScript и изучили, как часто в ответах появляются несуществующие пакеты. Их работу отметили наградой “Distinguished Paper Award” на конференции USENIX Security 2025.
Я пишу ядро операционной системы на Rust. Не потому что собираюсь заменить Linux, а потому что мне интересно, что получится, если закладывать безопасность в архитектуру с нуля, а не встраивать в готовое.
Довольно быстро выяснилась вещь, о которой в разговорах про Rust в системном программировании говорят реже, чем стоило бы. Язык закрывает один класс ошибок и оставляет другой нетронутым. И второй класс ловится куда хуже первого.
Расскажу про конкретный баг, который я ловил дольше всего.
Пока одни запускали GPT-5.6 Sol Max, другие ломали копья в холиварах «Kimi K3 vs Claude Opus 5», Alibaba тихо (ага, с ростом акций на 7% в моменте – очень тихо) вкатила модель, которую сама называет «новой планкой для кодинга и совместной работы». Знакомьтесь: Qwen3.8-Max, 2,4 триллиона параметров(всего-то), контекст на миллион токенов и обученная не просто быстро отвечать, а не сдаваться днями.
Привычный рефлекс «очередной китайский флагман – очередные астрономические циферки – очередное “мы почти догнали Anthropic”» отчасти правдив. Но тут три вещи, ради которых стоит потратить пять минут: во-первых, Alibaba внезапно впервые открывает веса модели Max-класса; во-вторых, независимая проверка разошлась с вендорскими цифрами, и это отдельная маленькая драма в твиттере; в-третьих – релиз подсвечивает тренд, который многие стараются не замечать – дело, возможно, не в модели, а в том, что вокруг неё построено.
Ну что, поехали. Разберём по порядку.
Скрипт, который упал, вы почините за пять минут. Скрипт, который отработал молча и выдал неправильный ответ, вы не почините никогда, потому что не узнаете, что он сломан.
В работе с FASTA и FASTQ таких мест неприлично много. Почти все они когда‑то были задуманы как удобство.
Вот три, с которыми я сталкивался чаще всего.
Первое. Инструмент пишет FASTQ, а качества у записи нет. Вместо ошибки он подставляет строку из I. Файл получается валидный, парсер доволен, а фильтр по качеству дальше по пайплайну видит идеальные риды и пропускает всё подряд.
Второе. R1 и R2 разъехались: один файл отфильтровали, второй забыли. На выходе абсолютно корректный FASTQ, просто риды спарены не с теми. Формат не нарушен ни в одном байте. Ни один валидатор не возразит.
Третье. Определение Phred‑кодировки по образцу, который одинаково хорошо подходит и под Phred+33, и под Phred+64. Инструмент молча выбирает вариант. Иногда правильный.
Общее у всех трёх одно: вместо ошибки вы получаете правдоподобный результат. И это худший из возможных исходов, потому что ошибку вы бы заметили.
Полгода назад я начал писать fastx, библиотеку и CLI для FASTA/FASTQ на Rust. Основное решение в ней сформулировано так: там, где можно либо угадать, либо признать неоднозначность, признавать неоднозначность.
Вышел Cozystack v1.6.0. Релиз опубликован 22 июля 2026 года и включает все исправления, ранее вышедшие в патч-релизах v1.5.1–v1.5.3. Ниже — перевод официального анонса, дополненный главными исправлениями из патч-релиза v1.6.1 от 5 августа.
В этом выпуске изменилось несколько важных частей платформы. Рабочие узлы тенантных кластеров Kubernetes теперь работают на Talos Linux вместо Ubuntu, тенанты могут включать аутентификацию OIDC для Kubernetes и Grafana, а новый API SecurityGroup даёт более безопасный интерфейс для управления сетевыми политиками приложений.
В статье рассматривается исполнительная часть утилиты ggrebalance: механизм физического перемещения primary- и mirror-сегментов между хостами кластера Greengage DB (open-source форк Greenplum), устройство конечного автомата ребаланса, отслеживание статусов операций, обработка сбоев и реентерабельность, откат перемещений, а также практические рекомендации по эксплуатации и итоговое сравнение с альтернативными инструментами.
Есть вещь, которую я до сих пор считаю лучшим, что случалось с развёртыванием Windows: ты подходишь к машине, выбираешь в начале всё, что тебе нужно, — и больше её не касаешься. Идёшь пить чай. Через несколько минут возвращаешься к готовому компьютеру с именем, в домене, с драйверами и софтом.
Это MDT. И его больше нет.
Дальше — история о том, как я в него влюбился, как он у меня разваливался, как я упёрся в стену, и что из этого получилось.
В обзорной статье мы разобрали, зачем использовать в поиске тот же UUID, что и в основной базе (если таковая имеется). Здесь сразу перейдём к практике: создадим таблицу, выполним основные операции через SQL и JSON API, а затем загрузим несколько документов через /bulk.
Все примеры рассчитаны на Manticore Search 28.5.0 или новее. Значение <generated UUID> в ответах обозначает UUID, который Manticore создаст при обработке запроса. Копировать эту строку в следующий запрос не нужно: подставьте фактический id из своего ответа.
Последние годы стали серьёзным испытанием для тестирования.
Нейросети существенно ускорили разработку кода: интеграция ИИ-помощников в IDE позволила за минуты решать задачи, на которые раньше нужны были часы. Качество иногда страдает, но высвобожденное время в сумме даёт положительный эффект, и в итоге количество поставляемого кода резко растёт.
В то же время пропускная способность QA принципиально не изменилась. Тестировщики тоже пользуются нейросетевыми помощниками, но им для успешной работы обычно нужно больше контекста — а значит, больше инфраструктуры.
В этой статье я хочу привлечь внимание к тому, насколько большую роль подготовка данных играет для нейросетей в QA. Конкретно, речь пойдёт о группировке падений перед анализом их причин. Я буду анализировать запуски инструментом для автоматической отладки багов — playwright-ai/auto-debug.
Привет, это Данил Киселев, сетевой инженер в Yandex Infrastructure. Представьте себе, что у вас не просто офис, а очень большой офис с тысячами пользователей, которые ходят с созвона на созвон, перемещаясь между переговорками. Разумеется, им хочется оставаться на связи в процессе и не думать о ближайших точках доступа к Wi‑Fi. Для сетевого инженера это не выглядит проблемой на небольших масштабах. Но что если скоро ваш офис вырастет и таких точек доступа в сетевой фабрике может стать уже 20 000 и больше?
В статье расскажу про опыт использования технологии VxLAN в корпоративных сетях Яндекса. В частности речь пойдёт про построение Wi‑Fi поверх VxLAN‑туннелей, которые таким образом смогли помочь нам с большим доменом и заодно избежать широковещательного шторма.
Год назад я написал здесь, что собрал на PHP/Laravel AI-агента, который способен рассуждать в циклах, потестил и остановился со словами «работает, но нужны идеи помощнее». Нужно что то необычное, новое.За год прототип оброс несколькими видами памяти, RAG, оркестрацией, зрением, голосом — и слоем, который даёт агенту что-то похожее на внутреннее состояние. Рассказываю, что выросло. Получился DepthNet 1.0
Сейчас активно идет пересмотр механизмов доверия к сертификатам, используемым для безопасного подключения к сайтам. Традиционные удостоверяющие центры, чьи корневые сертификаты зашиты в код операционных систем и браузеров, отозвали сертификаты для многих российских доменов. Это естественно подорвало к ним доверие. Отечественные центры, предлагаемые российскими госорганами, такое доверие пока еще не завоевали.
Допустим, у вашего товара в основной базе уже есть ID 550e8400-e29b-41d4-a716-446655440000. Он попадает в события, логи и ответы API. Но при загрузке того же товара в Manticore приложению приходится выдавать ему ещё один, числовой ID.
До Manticore Search 28.5.0 ID документа был беззнаковым 64-битным числом. UUID можно было сохранить в отдельном строковом атрибуте, однако идентификатором документа он от этого не становился. Для UPDATE, REPLACE и DELETE всё равно требовался числовой id.
В результате приходилось хранить соответствие между UUID из основной БД и числовым ID в таблице Manticore. Теперь без него можно обойтись: RT-таблица Manticore умеет использовать UUID как ID документа.
Мы делаем RCQ, мессенджер со сквозным шифрованием и открытым кодом (Android, iOS, протокол). В нашем основном регионе приложение блокируют, поэтому обход встроен внутрь клиента: sing-box в самом приложении, пул релеев, подписанный конфиг с их списком, запасной путь через CDN.
Всё это писалось месяцами и ни разу не измерялось. Мы знали, что механизмы есть, а срабатывают ли они хоть когда-нибудь и в каком проценте случаев, никто из нас сказать не мог, потому что спрашивать было не у чего.
В начале августа ушло двое суток на приборы. Ни одной новой функции, только измерение уже написанного. Нашлось восемь мест одной и той же формы: механизм построен, задеплоен, в него верят, а в продакшене он либо не выполнялся ни разу, либо выполнялся не так, как все были уверены.
Дальше про приборы. Обход блокировок тут просто предметная область, приёмы работают на любом коде, который включается редко и по чужому расписанию: ретраи, фолбэки, аварийные переключения, резервные каналы доставки.
В комментариях к прошлой статье мне написали примерно следующее: граф связей выглядит красиво, но хороший поиск по заметкам полезнее.
Спорить было трудно. Я сам регулярно открывал Obsidian, помнил, что где-то писал нужную мысль, но не помнил ни заголовок, ни точную формулировку. Обычный поиск в такой ситуации помогал примерно как человек, который на вопрос «где мои ключи?» отвечает «там, где ты их оставил».
Например, в заметке могло быть написано:
