Моя лента

Состоялся выпуск проекта Ocenaudio 3.22 на фреймворке Qt. Это бесплатный мультплатформенный аудио‑ и музыкальный редактор. Сборки проекта доступны для ПК на Windows (включая портативную версию), macOS и Linux. Предыдущая стабильная версия решения вышла в июле 2026 года.

В начале октября 2026 года состоялся релиз открытого мультиплатформенного инструментария MediaInfo 26.10 (системы унифицированного отображения наиболее важных технических данных и тегов для видео‑ и аудиофайлов) для просмотра и вывода информации по метаданным для аудио‑ и видеофайлов. У проекта также есть онлайн-версия. Исходный код решения опубликован под лицензией BSD. Предыдущий стабильный выпуск проекта случился в мае 2026 года.

В начале октября 2026 года разработчик Игорь Павлов представил версию открытого архиватора 7-Zip 26.04. Исходный код проекта написан на языке программирования C++ и опубликован на GitHub под лицензией LGPL. Разработка архиватора ведётся с января 1999 года. Решение переведено на 87 языков.

Представьте кластер Kubernetes, в котором нет ни одной сетевой карты. Его узлы ничего не знают ни о TCP/IP, ни даже об Ethernet и перекликаются по радио короткими пакетами по 32 байта, как прорабы по рациям на стройке. Управляющий слой написан на языке конца восьмидесятых и вместе с сетевым протоколом занимает около 1250 строк. Чтобы запустить под, ничего не нужно скачивать: узел просто загружает модуль и вызывает в нём процедуру. А главное, всё это открывается во вкладке браузера: можно выдернуть узел из розетки, заглушить эфир, подсунуть кластеру поддельную команду и посмотреть, что из этого выйдет.

Такой кластер я собрал за последние несколько недель и назвал его Kube. Это управляющий слой Kubernetes, написанный на Обероне, языке Никлауса Вирта, и работает он на машинах Оберона, то есть на процессоре и операционной системе, которые Вирт спроектировал сам, от схемы до окон на экране. Узлы Kube тоже машины Оберона, и разговаривают они по радиосети из той же книги: Вирт написал эту сеть для своих рабочих станций ещё в конце восьмидесятых, а в новой редакции проекта её перевели на дешёвый радиомодуль.

Доброго времени суток, уважаемые посетители Habr!
Данная статья будет короткой, но полезной.

В одной из предыдущих статей, уже описывал вычисление sin(x)/cos(x) с применением разложения в ряд Фурье с фиксированной точкой. Вычисление тригонометрических функций, в моем случае занимало порядка 125-130 тактов на пару (sin+cos) на процессорном ядре Cortex M7 (STM32H750). При этом, код компилировался для архитектуры Cortex M3. Точность sin/cos просчитанного таким образом составила менее 1.5LSB. Google посчитал ее как 1.2-1.3LSB, с минимальной дисперсией. Это уже дало динамический диапазон ~183dB. Для сравнения, полный динамический диапазон человеческого уха 120dB от болевого порога до шелеста листвы. А динамически диапазон звука который человек слышит одновременно порядка 40-60dB. Несколько позже поясню для чего приведено сравнение.

В общем и целом такого динамического диапазона и скорости уже достаточно чтобы производить операцию квадратурной свертки сигнала с частотой дискретизации до 450-500KHz. Кстати, на STM32F103C8T6, это заняло бы ~1.8uS на квадратурный отсчет. Т.е. с отключенными прерываниями процессор бы успел выполнить расчет одного бина честного преобразования Фурье в реальном времени. Это эквивалентно квадратурной демодуляцию на одной произвольной поднесущей до частоты 250КГц (хотя лучше брать Fsample/4 ), что позволяет работать с полосой до 125КГц, на простом контроллере в реальном времени.

Однако, этого мало для полноценной обработки сигналов. И тут я задумался. Как можно значительно повысить скорость работы и почти не потерять в точности? Первое что сделал,- разбил преобразование на блоки, фаза которых непрерывна. Это позволило работать с блоками отсчетов, которые, затем можно суммировать скользящим окном со сложностью O(1). Это привело к эффекту квадратурной демодуляции сигнала и без повышения сложности позволяло работать с малыми временными сдвигами. Фактически пришел к поблочной корреляция. Нечто вроде временного Rack-приема.

Когда я работал над своим проектом, всю информацию об инфраструктуре (серверы и их роли, хостинги, даты следующих оплат, DNS-записи...) я хранил в файлике на рабочем столе. Сначала это был обычный текстовый документ, чуть позже — таблица в LibreOffice Calc.

Пока серверов было меньше десятка, а хостингов — от силы два, мне было несложно раз в неделю сверять информацию в таблице с DNS-серверами, хостингами и собственным бэкендом.

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

Я устал от ретро, которые существуют, чтобы существовать.

Раз в две недели команда открывает Miro. Три колонки. Люди пишут то же, что на стендапе. Самый громкий через четыре минуты говорит «давайте заведём тикет». Стеснительные не пишут, потому что стикер с именем — это уже оценка. Action items живут в углу доски до следующей пятницы и исчезают без носителя. Фасилитатор чувствует вину, что «не хватило энергии», и в следующий раз приносит новую рамку: wow/now/how, sailboat, 4Ls. Рамка меняется, стол — нет.

Я несколько раз попал в длинные очереди за бензином, конкретно за АИ‑95. В конце августа четыре часа простоял в очереди на московской заправке, чтобы заправиться за минуту. В другой раз два часа ждал в Моршанске, хотя это город с населением меньше 50 тысяч человек. Очереди меня жутко выбешивали, поэтому решил навайбкодить монитор бензина. Он должен был сообщать, когда бензин появляется на нужной заправке и туда можно ехать. И у меня это получилось, хотя самостоятельно я до этого ничего не разрабатывал.

На связи Игорь, менеджер продуктов Outlines Tech. В статье покажу, как ставил задачу ChatGPT, что приходилось уточнять и как проверил инструмент в деле. В конце оставлю ссылку на код на GitHub, чтобы вы могли попробовать его у себя. Бесплатно, разумеется.

Обновлённый логотип появился как в macOS 27.2 beta 3, так и в iOS 27.2 beta 3. Он идентичен тому, который Apple использовала в своём анонсе открытия концертного зала Apple Music Hall в прошлом месяце, пишет MacRumors.

Большая часть материалов про Claude Code написана под macOS и Linux. У меня часть задач завязана на Windows, в первую очередь браузерная автоматизация с живыми профилями Chrome, поэтому агент работает прямо в нативном окружении, без WSL. Сам Claude Code под Windows ведёт себя стабильно. Проблемы возникают на стыке с окружением: PowerShell 5.1, кодировки, имена процессов, PATH.

Каждую такую мелочь я в итоге записывал агенту в память, чтобы он больше не наступал туда же. Набралось пять штук, плюс блок для CLAUDE.md в конце, который можно забрать себе целиком. Если вы тоже на Windows и без WSL, возможно, это сэкономит вам пару вечеров.

Итан Сигел (американский астрофизик‑теоретик и научный журналист, автор рубрики «Спросите Итана», один из пропагандистов современных научных знаний), спешит рассказать подробнее, за что дали Нобелевскую премию по физике 2026 года, причем одному-единственному человеку, Фрэнсису Халцену.

@avshkol , в свою очередь, оперативно перевел эту статью, поскольку мы наблюдаем действительно редкий случай: один лауреат, и не за научное открытие, а за постановку очень сложного эксперимента, да ещё он был далеко не единственным (есть ещё русские на Байкале, с 1980-х строящие не меньших размеров телескоп и японцы, впервые поймавшие нейтрино от сверхновой)...

_{*Статья дается в развитие темы, мной обозначенной ранее (Когда «Да, шеф!» убивает компанию)}

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

Как антикризисный управляющий, я регулярно захожу на объекты, где фасад управления выглядит безупречно, а внутри ИТ-структура уже бьется в конвульсиях.

Бизнес редко умирает мгновенно, его усыпляют прекрасными отчетами.

Анатомия «испорченного телефона»

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

Выглядит эта микро-пьеса примерно так:

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

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

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

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

Данная статья подводит итоги проекта 435nm, в рамках которого за десять лет был создан прототип биологической системы жизнеобеспечения на микроводорослях.

В статье описана причина появления проекта, даны основные этапы его развития, рассказано о решенных и нерешенных технических, биологических и организационных проблемах, приведен список участников проекта на разных стадиях и намечены перспективы развития этого направления.

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

В тексте встречаются местоимения “я” и “мы”. Я — это автор этого текста и руководитель проекта 435nm, Александр Шаенко, мы — это команда проекта 435nm.

Одноклеточные фотоавтотрофы и фанерные биореакторы, математические модели и кислородные концентраторы, кривые роста и поиски инвестиций, неудачные решения и великолепные открытия ждут вас!

Начнем же!

Как сделать GeoAI-агента, который сам из космоса ищет пожары и отправляет к этим местам пожарные расчеты и беспилотные летательные аппараты. Fire Monitor (Стрела) - это умная система мониторинга лесных пожаров, которой управляет полноценный GeoAI-агент. Она сама собирает термоточки со спутников VIIRS и MODIS, оценивает масштабы выгорания территории по снимкам Santinel-2, строит маршруты от ближайших пожарных частей к очагу по дорожной сети для пожарных машин и даже рассчитывает траектории (галсы) для облета территории беспилотниками.

Где заканчивается парсинг и начинается решение

Предыстория: около месяца назад подробно обсуждал архитектуру этого проекта в личке с хабровчанкой (не имею права раскрывать ник). Она набросала мощные хардкорные идеи: прикрутить предохранитель на объем выдачи, внедрить счетчик пропусков missed_runs для отсечения ложных удалений и использовать сессии Telethon. До реализации её паттернов руки всё никак не доходили (да и заказчик активно пользовался проектом). Момент настал, а вчера OpenAI выкатила GPT-6 Luna Decisions с её Decisions API. И тут мне в голову пришла альтернативная мысль, о которой эта статья. Мне крайне интересно мнение со стороны касательно изменения проекта.

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

Мне интересна именно эта граница. В схеме на n8n изменения находит обычный код, а текстовая модель составляет отчёт. Пока человек читает весь отчёт, это удобное разделение. Если хочется отправлять отдельные уведомления, оценку из текста уже нужно переделать в машинное решение.

В описании Luna Decisions на OpenRouter меня заинтересовал подход: модель возвращает типизированные оценки, а приложение само выбирает действие. Не «напиши, насколько это интересно», а отдельный результат, который можно проверить, сохранить и сравнить с порогом.

Но из этого ещё не следует, что такой API нужен в моём случае. Ниже разберу, куда его можно встроить, чего не хватает во входных данных и с чем я бы сравнивал результат. Возможно, после сравнения окажется, что достаточно нескольких условий в Code-ноде. Это тоже полезный исход.

6 октября Google DeepMind выпустила EmbeddingGemma 2 — компактную open-weight модель для embeddings, которая умеет работать не только с текстом и кодом, но и с изображениями, видео и аудио. Спустя сутки релиз уже появился в локальном стеке разработчиков, а первые сравнения показывают более неоднозначную картину, чем следует из формулировки Google о «лучшем в классе».

Главная идея модели — собрать разные типы данных в единое 768-мерное пространство. Поэтому текстовый запрос можно сопоставлять с изображениями, аудио или видеокадрами без отдельной цепочки из speech-to-text, image captioning и нескольких embedding-моделей. Google рассчитывает таким образом упростить локальный семантический поиск, RAG, классификацию и маршрутизацию.

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

Как правило, кольцевой буфер реализуется через списки, вроде std::list или std::deque, либо через плоские массивы, вроде std::vector или boost::circular_buffer. Но ни одна реализация не гарантирует непрерывность и упорядоченность одновременно. В данной статье я расскажу про реализацию буфера через трюк с виртуальной памятью, сохраняющую упорядоченность элементов в непрерывной ограниченной области памяти.

В этой части разберём, зачем Kubernetes понадобился Gateway API, если уже существует Ingress. На простом примере посмотрим, как Gateway и HTTPRoute разделяют точку входа и маршрутизацию, зачем нужен GatewayClass и почему такая модель удобна, когда кластер и приложения обслуживают разные команды.

Можно ли позаимствовать у мозга мухи способ накапливать индивидуальный опыт — и использовать его для персонализации прогнозов? Я backend-разработчик и начинающий в ML. Исследуя предсказание пищевых срывов, я взял фрагмент коннектома дрозофилы, отделил общую модель от персональной памяти и проверил конструкцию на синтетических данных.

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