Open source *

Помните, как полтора-два года назад в коротких видео стали появляться видео сомнительного качества, которые можно с легкостью пометить как сгенерированные? С тех пор их количество заметно упало. 

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

Я играю на пианино с детства. Классика, саундтреки, импровизации – репертуар меняется, но привычка спонтанно сесть за клавиши остается. Лучший способ отдохнуть, переключить голову после сложной работы или вообще просто так!  На моей домашней рабочей станции установлен профессиональный синтезатор фортепиано Pianoteq от Modartt — он полностью меня устраивает: не только реалистичностью звучания, но и возможностью экспериментировать со звуком.

Достаточно давно  я собрал умную дачу на базе ПЛК под Linux и даже написал об этом статью. Контроллер исправно управляет освещением, водоснабжением и отоплением. Потом я прочитал статью о запуске Doom на этом контроллере и задумался: смогу ли приспособить его под свое хобби? Получится ли играть на даче не хуже, чем дома? 

Doom — задача хоть и культовая, но все-таки относительно простая. А справится ли контроллер с real-time-синтезом аудио? Здесь недостаточно просто воспроизводить заранее записанный звук — нужно в реальном времени рассчитывать его по физической модели инструмента. 

Сборки Pianoteq существуют под разные архитектуры, но чаще всего его используют на студийных Mac и рабочих станциях — на сцене, в студиях и при работе над киномузыкой.

Итак, для своего эксперимента я привез на дачу USB-ЦАП, MIDI-клавиатуру с педалью и подключил их к контроллеру…

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

В прошлые разы я разбирал, как мы встроили обход блокировок прямо в iOS-приложение: sing-box внутри бинарника, VLESS + Reality, relay как расходник, конфиг отдельно от сборки. Та статья закрывала ровно одну задачу: довести трафик мессенджера до сервера там, где прямое соединение режется.

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

Вот про эту дыру и будет текст. Она называется красиво: метаданные. На практике это означает, что один relay видит больше, чем должен. И мы её закрыли, не трогая боевой парк relay вообще. Без маркетинга, по делу.

Многие блогеры и даже инвестиционные книги активно пропагандируют эту идею: «Купи широкий рынок и держи его долгие годы. Время и сложный процент сделают своё дело». 

Так ли это на самом деле? 

В статье рассматриваю простой вариант купи и держи, когда инвестор один раз покупает индекс и затем ничего не делает в течение нескольких лет.

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

Для американского рынка взял индекс S&P 500, данные доступны с 1871 года, скачал отсюда: https://github.com/datasets/s‑and‑p-500

Для российского рынка хотел взять Индекс полной доходности МосБиржи (MCFTR), но он только с 2003 года доступен, поэтому взял Индекс МосБиржи (IMOEX) там данные с 1997, скачал с официального сайта: https://www.moex.com/ru/factsheet/history.

Все свои расчёты я выложил на GitHub для проверки или если вы заинтересуетесь методологией.

Первоначально у меня было предположение что для американского рынка это работает, потому что есть множество книг по инвестициям и они американские, но можно ли натянуть Уоррена Баффета на российские реалии?

Заходят как-то две машины Тьюринга в одну диаграмму… а у них имена одинаковые.

Я говорю «машины», а на деле — два разных экземпляра State @turing-machine-js/machine, сконструированные по-разному, с разным поведением во время исполнения, и со строго одинаковым state.name. Это происходило в библиотеке, которую я разрабатываю в качестве хобби с 2019 года, и я этого не замечал семь лет.

Обнаружил случайно, начиная с задачи на чистку Mermaid-визуализации. Закончил — кардинальной переделкой того, как композиция состояний отражается в имени. И узнал, что за этой переделкой прячется число .

Telegram запускает Digital Freedom Contest — конкурс для контент-креаторов с призовым фондом $200 000 (!). Задача: сделать вирусное видео про цифровую свободу, использовать идеи и кадры из речи Павла Дурова, выложить ролик в TikTok, Instagram, YouTube, Snapchat Spotlight или X и набрать минимум 10 000 органических просмотров.

Дедлайн — 15 июля, 23:59 по Дубаю. Результаты — в августе 2026 года.

Но у меня, как у человека из сообщества Telemt, есть один неприятный вопрос: ребята, а может сначала инфру пофиксите, на которой эта цифровая свобода вообще держится??

Год назад доступ к зарубежным LLM из России превратился в квест. OpenAI и Anthropic не принимают российские карты и блокируют запросы по гео. Обходные пути — VPN, иностранная карта, прокладка через знакомых за рубежом — годятся для пет-проекта, но не для продакшена, где нужен стабильный аккаунт, предсказуемый счёт и возможность объяснить бухгалтерии, за что платим.

Мы сделали apiglue — шлюз, который закрывает эту боль: один OpenAI-совместимый endpoint, за которым прячутся десятки провайдеров, оплата рублёвой картой и баланс в рублях. А заодно — управляемый хостинг n8n, чтобы не только дёргать модели через API, но и собирать на них автоматизации без своего сервера.

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

Всем привет! Я Антон, системный аналитик из команды трансграничных переводов в Uzum Fintech, и от меня уже два месяца ждут текст по результатам выступления на внутреннем митапе.

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

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

Тогда это звучало как начало анекдота, но мне было не до смеха.

С тех пор я сменил работу. И, как будто вселенная решила проверить моё чувство юмора, я снова вижу API, где контракт живёт рядом с кодом в ручных #[OA\...] атрибутах.

И это важный момент. Это не история про одну конкретную компанию, один неудачный проект или один старый сервис, который все боятся трогать. Я вижу этот подход в разных местах.

Роли между популярными нейросетями более-менее распределены.

ChatGPT остается главным универсальным помощником для большинства пользователей. Claude считается одним из лучших инструментов для программирования. Grok постепенно превращается в встроенного собеседника для аудитории X. А DeepSeek завоевал популярность как мощная и при этом относительно недорогая альтернатива американским моделям.

Кому нужна еще одна китайская нейросеть — Qwen?

Разбираемся, что это такое, чем она отличается от DeepSeek и может ли занять свое место на переполненном рынке нейросетей.

Третья, заключительная статья из цикла.

Часть 1 — где LLM теряет межсервисный контекст и почему локальных спек недостаточно.

Часть 2 — archspec как контракт вместо свободного Markdown.

Часть 3 — archspec investigate: исследование фичи, обновление контрактов и реализация.

В части 1 я показал, что spec-driven development с LLM начинает ошибаться, когда фича проходит через несколько микросервисов: по отдельности каждый сервис выглядит аккуратно, а вместе система работает не так, как нужно. Модель теряет межсервисный контекст — правила, которые живут на границах между сервисами, не записаны в одном месте, и LLM их пропускает. В части 2 я собрал archspec: на каждый сервис генерируется машиночитаемый контракт SERVICE_MAP.yaml, который делает эти правила явными.

В этой части я беру ту же фичу — автоматическое переназначение задачи после отказа фрилансера — и прогоняю её заново через /archspec:investigate, но уже поверх контрактов. Тот же промпт, та же модель (Claude Sonnet 4.6). Вопрос один: поймает ли план те межсервисные ошибки, на которых в первый раз фича не сошлась, ещё до написания кода — и где спотыкается уже сам инструмент.

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

Это была бы скучная заметка в духе «МАС не нужен, расходимся». Но нашлось исключение. Чем труднее задача для модели, тем больше у команды появляется шанс на выигрыш. Так что вопросов у меня два. Влияет ли вообще топология системы на результат? И если влияет, можно ли автоматически выбирать подходящий паттерн под конкретную задачу? Ответ на второй вопрос пока отрицательный, и самое любопытное здесь именно почему.

Примеры я показываю на мультиагентном фреймворке FEDOT.MAS, а весь код экспериментов с паттернами, прогонами и графиками лежит в репозитории. Я меряю инструмент, который сам и пишу. Но и выводы выйдут в основном не в пользу мультиагентности, так что это скорее самокритика, чем реклама.

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

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

У Firefox для этого есть корпоративные политики. Их можно описывать в policies.json, раскладывать по рабочим станциям и получать управляемый браузер. Но между «политики существуют» и «администратор или специалист по информационной безопасности может уверенно сопровождать их в реальной организации» есть большая дистанция.

Так появился Browser Policy Manager — свободный продукт под лицензией MPL-2.0 для управления корпоративными политиками Firefox.

Есть задачи, которые не делаются никогда. Не потому что сложные, а потому что объём убивает любое намерение на втором часу. У меня такой задачей был фотоархив: около 36 000 фото и видео, 222 ГБ, копившиеся 20 лет и размазанные вообще везде. Время пришло :)

В каждой лаборатории один и тот же биомаркер называют по-своему, и кажется логичным «схлопнуть все синонимы в один код». Но это работает ровно наполовину: LOINC-код — это не название анализа, а шесть осей (что, чем, где, как измерили), и рядом нужен UCUM для единиц.

Почему «синонимы → код» — ловушка, зачем нужны и LOINC, и UCUM, как это ложится в OMOP для RWE и почему финальный код нельзя доверить языковой модели. Референсная архитектура на бумаге — и честно про путь.

Как превратить крик души в работающую утилиту и попасть в официальную ArchWiki? Мне 17 лет, и мне просто надоело тянуть HDMI-кабель от ноутбука к телевизору через всю комнату. В этой статье я расскажу, как написал свой стример экрана FluxCast на Python, с какими багами Smart TV пришлось столкнуться и как устроен «слепой» дебаг проприетарного железа по логам пользователей со всего мира.

В рамках проекта etcd-operator сообщество развивает оператор для развёртывания и сопровождения кластеров etcd в Kubernetes. На днях он был передан проекту Cozystack (CNCF Sandbox). Перед этим команда опубликовала написанную с нуля реализацию оператора с новой версией API — etcd-operator.cozystack.io/v1alpha2. Эта версия пришла на смену etcd.aenix.io/v1alpha1. Вместо управления узлами через StatefulSet новый оператор напрямую задействует штатный Membership API etcd (операции MemberAdd, MemberPromote и MemberRemove), что позволяет ему полностью контролировать состав кластера. Автор новой реализации — Тимофей Ларкин, один из мейнтейнеров прежнего оператора (старый код остался в ветке v1alpha1). Проект написан на Go и распространяется под лицензией Apache 2.0.

Китайские модели дешевле западных в разы, и регулярно всплывает вопрос: можно ли просто пересесть на Qwen и не платить за Claude с GPT? Я взял одну реальную задачу — разбор pprof-профиля Go-сервиса с фиксами по файлам — и прогнал её через три модели сразу: Codex (GPT-5.5), Claude Opus 4.8 и Qwen 3.7 Max. Свёл качество (по 10 критериям) с реальной ценой за токены и разбираю, где Qwen работает наравне с дорогими конкурентами, где отстаёт по глубине, где выдал прямо небезопасный совет, и кому он в итоге подойдёт. Спойлер: дело не в «IQ модели», а в том, что одиночная модель — хоть дорогая, хоть дешёвая — слепа к своим ошибкам.

WireGuard довольно быстро стал популярным VPN-протоколом: простой, быстрый, с аккуратной архитектурой и без тяжёлого наследия, он выгодно выделялся на фоне монстров вроде IPsec и OpenVPN. Но, как это часто бывает, сильная сторона со временем стала и слабым местом. Протокол оказался не только удобным и предсказуемым, но и легко узнаваемым, а значит и сравнительно простым для блокировки.

Как только WireGuard начали пытаться блокировать, появились и первые попытки его спрятать. Сначала это были довольно простые приёмы, например, добавить перед хендшейком несколько мусорных UDP-пакетов, чтобы сбить DPI в начале сессии. Потом появилась AmneziaWG, которая пошла дальше и стала менять уже сам внешний вид WireGuard-пакетов: заголовки, размеры, дополнительные junk-данные внутри хендшейка. В AmneziaWG 2.0 пространства для манёвра стало ещё больше: к уже существовавшим S1–S2 добавились S3–S4, и управляемые вставки стало возможно применять не только к хендшейку, но и к другим типам сообщений, включая основной поток данных. Параллельно развивалась и идея имитационных пакетов: перед хендшейком можно было отправлять не просто случайный мусор, а пакеты, похожие на трафик другого протокола, чтобы сбить первичную классификацию.

В этой статье речь пойдёт о следующем шаге в развитии этой идеи. Если раньше имитационные пакеты работали в основном как короткая дымовая завеса перед хендшейком, то теперь имитация переносится в сам поток: транспортные пакеты AmneziaWG на проводе начинают выглядеть как QUIC, DNS, STUN или SIP.