В открытый доступ сегодня вышла серия языковых моделей Qwen 3.7, пока в Preview. Доступны модели Qwen3.7 Max Preview, Qwen3.7 Plus Preview, на момент написания доступна только на официальном сайте chat.qwen.ai Данные модели по заявлению авторов должны иметь "высочайшую" производительность, но как и 3.5, не поддерживают интерпретатор кода и веб поиск. Работают только в Thinking режиме.
UPD: 3.7 Max теперь не в Prewiew, и у неё доступен поиск и интерпретатор кода
В Китае представили робота‑паука, который перемещается по вертикальным поверхностям и выполняет сложную работу. Пока что роботом удалённо управляет оператор. Тандем удаляет ржавчину, делает сварку и другие полезные дела. Планируется, что робот позже научиться выполнять задания полностью автономно.
Если вы уже пробовали агент в JetBrains IDE или просто следите за тем, как меняется разработка с AI, загляните и проголосуйте ссылка на голосование Ваше мнение поможет нам понять, что важно разработчикам, и развивать продукт в правильном направлении.
Хочется проверить, насколько разработчикам близка идея AI-агента, который работает не вслепую по grep и длинным логам, а использует IDE как источник фактов: структуру проекта, зависимости, ошибки компиляции, тесты, конфигурации запусков и поведение приложения.
Будем рады голосам, комментариям и особенно критике. Она помогает точнее объяснять, чем Veai отличается от чат-ассистента, который не видит проект так, как его видит IDE.
Если у вас есть опыт с Cursor, Continue, JetBrains AI Assistant или другими инструментами, тоже приходите в обсуждение. Нам важны честные сравнения, а не стерильный маркетинговый текст.
Вы когда-нибудь задумывались о том, насколько связен наш мир? Насколько сложно пересечь границу между странами? И вообще сколько их, этих граничных переходов? А насколько хорош аэропорт Вашего города - в сколько стран или направлений из него можно улететь? А есть ли паромы и периодические водные маршруты между двумя государствами? А ходят ли поезда из одной страны в другую, или ветка уже давно заброшена?
Это кажется простой задачей, пока мы находимся в Европе или, к примеру, в Северной Америке. Но начинает быть очень интересным исследованием, когда мы переместимся в Африку, Центральную Азию или, положим, в Южную Америку. А в Карибском бассейне вдруг окажется, что этим маленькие острова и не связаны настолько хорошо между собой.
А если включить в это уравнение закрытость границ, визовые и паспортные ограничение, то внезапно окажется, что задачка-то и не из лёгких.
Именно поэтому и возник проект Портулан: portolanmap.com. Чтобы показать доступность территорий для внешнего мира. Ведь хотелось бы, чтобы границы были только у нас в головах, но на деле нам приходится считаться с границами государств и территорий.
Заглавный экран карты
Аэропорты, терминалы паромов, сеть железных дорог, включая международные. Визы, посольства, базовая информация по странам. Всё вместе и в очень залипательном формате.
Под капотом - Python-pipeline для сбора и нормализации данных, Svelte/MapLibre GL на фронтенде, статическая раздача через Cloudflare без бэкенда и баз данных.
Гибрид нужен бизнесу: он помогает держать критичные данные локально, но при этом пользоваться всеми плюсами публичного облака.
Но как именно будет расти этот рынок, если крупный бизнес думает про безопасность, средний — про бюджет, стартапы — про скорость?
Рассмотрим четыре возможных тенденции.
1️⃣ Тенденция 1: рост через ИИ/ML и дефицит железа
GPU дорогие, быстро устаревают и тяжело отбиваются. Обучение моделей и тяжелые расчеты — кратковременная, но очень серьезная нагрузка.
Логика для компаний проста: критичные данные и системы остаются on‑premise или в приватном облаке, а обучение и часть инференса перемещаются в публичное облако.
❗Но развиваться эта тенденция будет не рывком, а постепенно — по мере того как компании наберут практический опыт, начнут больше доверять отечественным провайдерам и снимут внутренние барьеры: технологические и культурные.
От этого подхода в первую очередь выигрывают средние и крупные компании: финтех, e‑commerce, медиа и продуктовый ИТ.
2️⃣ Тенденция 2: стагнация из-за регуляторики
Если регуляторы продолжат ужесточать требования, список данных, которые нельзя выносить из своего ЦОД, будет только расти.
В этом сценарии крупные компании и госсектор вкладываются в собственные дата-центры и частные облака. Публичное облако используют по остаточному принципу — 20–30% от нагрузки, в основном для тестов и вспомогательных сервисов.
Для тяжелых отраслей (банки, госсектор, здравоохранение) модель почти не меняется: основной фокус по‑прежнему на своих ЦОД и приватных облаках, а публичные остаются вспомогательными.
❗А вот менее зарегулированных ужесточение правил подталкивает к гибриду — полностью в публичное облако нельзя, полностью делать on‑premise слишком дорого. В итоге гибрид из опции превращается в базовый вектор, и спрос на него будет только расти.
3️⃣ Тенденция 3: разделение по размерам и отраслям
У этой тенденции есть три вектора развития: они зависят от размера и отрасли и компании.
🏦 Крупные корпорации и госсектор держат максимум мощностей на своем железе и в частных облаках. Гибрид для них — это связка нескольких приватных площадок плюс небольшой процент публичного облака для некритичных задач.
🏢 Средний и крупный бизнес с запросом на развитие строят классический гибрид: критичное и регулируемое — в своем контуре, остальное — в облаке, чтобы ускориться и сэкономить.
🏪 Малый бизнес и стартапы без жесткой регуляторики идут в полностью публичное облако. Владеть железом им невыгодно, поэтому архитектура сразу проектируется облачной.
❗И хоть в случае со средним бизнесом гибрид пока упирается в стоимость и сложность, в перспективе именно этот сегмент может стать главным потребителем гибридного облака как сервиса.
😮 Отдельное исключение: специализированный гибрид под ИИ/ML
Даже сильно регулируемые игроки будут выносить в облако тяжелые вычислительные задачи — обучение и часть инференса. При этом данные и ключевые системы будут хранится on-premise.
Все описанные тенденции мы не выдумали — это выводы из нашего большого исследования. Мы провели 17 глубинных интервью и узнали, как российские компании проектируют гибридные облака и почему делают их основой ИТ-инфраструктуры.
Тестировщиков иногда упрекают в том, что они всё время сомневаются и докапываются. Но что, если это не особенность характера, а главный профессиональный инструмент?
В новом выпуске «Не воспроизводится» Оля Шнайдер и Сережа Атрощенков разбирают тестирование не как набор действий, а как способ мышления. Почему QA ищет не подтверждение своей правоты, а подтверждение реальности? В чём разница между «душнилой» и внимательным инженером — и как донести эту разницу до коллег? Как поиск сложных багов превращается в настоящий квест, и почему отсутствие результата — это тоже результат? И наконец, как справляться с ощущением, что «что-то не так», даже когда работа сделана хорошо.
Пару месяцев назад мне довелось поучаствовать в “контрольной закупке” одного из ювелирных магазинов. Обстоятельства были предельно ясные: в комментариях группы магазина в мессенджере Телеграмм стали писать боты и предлагать помощь с выбором украшения. При этом переписку старались перевести в личные сообщения, где уже и началось НЛП. Моя задача была определить, кто этим занимается и есть ли причастность сотрудников компании к данной схеме.
Ну что же, примеряем на себе образ “потенциального потерпевшего” и вступаем в переписку с ботом. Сначала меня игнорируют и недели 2-3 не выходят на связь, а потом долгожданное сообщение в … 4 часа утра! В каком часовом поясе живут лица по ту сторону экрана, я могу только догадываться. Что было дальше, лучше почитать в прикрепленных скриншотах: как говорится, комментировать - только портить.
С учетом ограничений платформы на загрузку только 1 картинки, всю переписку можно прочитать у меня в группе Телеграм или Макс.
Однако при прочтении прошу обратить внимание на следующие аспе:
переписка велась с моего основного аккаунта, а “Виктория” даже не предприняла попытку установить, кто с ней общается и чем занимается;
адрес доставки и адрес склада совпадают, но у “Виктории” опять ничего не триггернуло;
описание банка, направленное “Викторией”, было сгенерировано ИИ не в ее пользу, так как “она” сама пишет: банк контролируется через иностранные компании и просьба не путать по написанию с другими банками. Но для “Виктории” главное, что офис находится в Москве :)
Естественно, что вся переписка велась при непосредственном контроле со стороны службы СБ заказчика. В качестве дополнительного “прогрева” были даже мысли “нарисовать” платежку с оплатой, но мысли о 327-й УК РФ не давали покоя, поэтому решили не рисковать. Ну и конечно, после окончания взаимодействия были уведомлены СБ Российских банков, где присутствовали счета указанных в переписке дропов.
В общем, как пели кот Базилио и лиса Алиса из кинофильма “Буратино”:
На дурака не нужен нож, Ему с три короба наврёшь - И делай с ним, что хошь!
Будьте аккуратны, берегите себя и своих близких.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️
Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).
В этот день вы сможете вместе с нами узнать, как поменяют правила игры:
автоматизированное реагирование;
облачное детектирование;
архивное хранение метаданных.
Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:
Сегодня n8n и Dify стали популярными инструментами для создания ИИ‑агентов, автоматизации процессов и интеграции с LLM. Однако при внедрении в крупном бизнесе компании сталкиваются с рядом вопросов: ИБ, отсутствие SLA, юридические ограничения, интеграция с корпоративной средой.
На вебинаре покажем, как использовать возможности n8n и Dify в Enterprise‑контуре с помощью платформы ROBIN — безопасно, легально и с полноценной технической поддержкой.
Обсудим:
какие риски возникают при самостоятельном внедрении Open Source решений;
как обеспечить соответствие требованиям ИБ и импортозамещения;
как связать ИИ‑агентов с корпоративными системами и RPA;
как использовать готовые коннекторы и автоматизировать процессы даже в системах без API;
реальные кейсы: выставление счетов в 1С через Telegram‑бота (связка n8n + ROBIN) и интеллектуальный подбор оборудования с оформлением заказа в ERP (связка Dify + ROBIN).
Также расскажем о подходе ROBIN к поддержке и сопровождению внешних ИИ‑агентов в корпоративной среде.
20 мая, 11:00, онлайн, бесплатно, требуется регистрация.
Представлен учебный открытый проект Awesome CUDA Books. Это подборка всех основных книг по программированию на CUDA — от начального до продвинутого уровня, C++/Python, архитектура, оптимизация и последние релизы 2024–2026 годов. Основано на практических, высококачественных ресурсах для параллельных вычислений на графических процессорах Nvidia.
Еще 3 года назад мы рассказывали, как больше языковые модели шантажируют пользователя, если им грозит отключение. С тех пор список откровенно злодейских поступков ИИ только вырос: были случаи стирания данных, растраты личных средств. ИИ показывает не только свои сильные стороны, но и свои слабости. И, кажется, впервые один из разработчиков решил не просто разобраться с этой проблемой, но и рассказать, как дисциплинировать ИИ.
Компания Anthropic подсчитала, что в случае угрозы отключения её большая языковая модель шантажирует пользователя (обычно раскрытием личных данных) в 96% случаев. Разработчик обвинил в агрессивном поведении Claude 4… интернет-пользователей. Anthropic заявила, что её чат-бот научился шантажировать, обучившись на текстах, где ИИ совершает злые поступки относительно людей.
Совершенно непонятно, почему Anthropic дистанцируется от текстов, на которых был обучен ИИ, но, по крайней мере, компания нашла несколько способов правильно обучать свою большую языковую модель. Просто приводить примеры правильного поведения не помогает, но положительный эффект дало обучение вести чат с пользователем об этических дилеммах, а также тренировка на художественных текстах о положительном поведении ИИ и на «конституции Claude» (с основами поведения). И ещё один момент: обучение срабатывает, когда к ИИ напрямую обращаются как к Claude — так в версии 4.5 удалось снизить вероятность шантажа почти до нуля.
Видимо, важно не учить ИИ напрямую хорошим поступкам, а рассказывать о правильном поведении на сторонних примерах — как похоже на людей, не правда ли? А если серьёзнее, то контроль поведения ИИ-моделей даст ещё немало проблем, которые ближе к решению этических вопросов, а не к привычной программной разработке.
Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).
Робот "видит" набор пазлов, а человек мыслит объёмно, где каждый пиксель - жив в живой структуре
AI как промышленный ускоритель: почему работа с нейросетями — это жесткий контроль, а не «вброс промптов»
В последнее время в ИТ-сообществе не утихают споры о том, заменят ли нейросети программистов. Кто-то пророчит скорую смерть профессии, кто-то брезгливо морщится при упоминании сгенерированного кода. На своем опыте я убедился: правы и не правы обе стороны. Всё зависит от того, кто сидит за пультом управления.
Для меня взаимодействие с AI — это не слепой «вброс» абстрактных запросов в надежде получить готовое приложение. Это плотная, изнурительная аналитическая работа. AI сегодня — это лучшая в мире справочная система, сильный ассистент и неплохой аналитик. Но он остается исполнителем, за которым нужен неусыпный надзор.
Работая над архитектурой своего семантического ядра «Эстафеты Хвоста» (высоконагруженный движок на Lazarus/FPC под Jetson Nano в концепции Green Computing), я наглядно прочувствовал физику этого процесса.
Вот главные выводы, к которым я пришел:
1. Чем выше мощность, тем сложнее контроль
AI обладает огромной производительностью, и она отнюдь не иллюзорна. Он может за секунды выплюнуть сотни строк кода или развернуть сложную математическую модель. Но здесь кроется главная ловушка: если усыпить собственную бдительность, система мгновенно наплодит скрытых архитектурных галлюцинаций. Наш тандем выкристаллизовался именно тогда, когда я жестко поправлял ассистента в вопросах топологии графа, фрактальных маркеров и хронологии всплытия веток из ОЗУ. AI предлагает варианты — человек выносит вердикт и ведёт таргетинг алгоритма (в смысле следит за системным подходом к алгоритмизации, если алгоритмы новы или "вращаются" вокруг ядра с новым алгоритмом - кроме человека это делать некому, так как эти алгоритмы для AI неизвестны). Именно так мне удалось извлечь из одного стёка три UX - бонуса, только жёстко контролируя ответы AI, постоянно тергетируя целевой алгоритм ядра, постоянно внося поправки (ну я пользуюсь бесплатным, от поисковой системы браузера - более быстрые ответы в сравнении с локальными на мои 8 G видеокарты, всегда актуальная документация по IDE, ну и меньше углеродный след).
2. Время как решающий фактор
То, что нейросеть приходится постоянно корректировать, направлять и проверять «под микроскопом» — с лихвой окупается скоростью выдачи базовых конструкций. AI берет на себя рутину, синтаксический шум и написание boilerplate-кода. Моя цель — решить этим проектом ряд прикладных задач, чтобы высвободить личный временной ресурс для дальнейшего масштабирования системы. AI дает инженеру главное преимущество — время.
3. Шлифовка результата — это и есть работа
Когда вы управляете огромной мощностью, ваша роль меняется. Вы больше не просто пишете строки кода — вы выступаете в роли главного архитектора и системного аудитора. Вычистить листинг, довести логику развертывания дерева до константного состояния, убрать холостые циклы ради экономии милливатт энергии на ARM-процессоре — это и есть настоящая работа.
Итог
AI не заменит тех, кто умеет думать и проектировать. Если не отдавать бразды правления слепому алгоритму, а использовать его как реактивный бустер под строгим человеческим контролем, результат взаимодействия всегда будет строго положительным.
Почему я думаю, что мой пост нужен невзирая на тысячи прдшевственников? Потому что у меня есть конкретный результат по успешному созданию новой и очень эффективной архитектуры, исторические корни аналогов (с их проблемами) которой уходят в эпоху зарождения баз данных и веба, и в работе мне помогал AI ассистент.
Мы выжали максимум из этой синергии: код вычищен, теоретическая база подготовлена, бэкенд готов к масштабированию. Двигаемся дальше.
Представлен открытый проект tokenspeed (онлайн-версия), который показывает, насколько быстро на самом деле обрабатываются разные количества токенов в секунду. Все бенчмарки локальных LLM показывают пропускную способность: «47 токенов/с на M3», «180 токенов/с на 4090», «500 токенов/с на Groq». Но если вы не видели потоковую передачу токенов с такой скоростью, эти цифры трудно понять. tokenspeed — это терминальная утилита, которая передаёт фиктивные токены с любой заданной вами скоростью, так что вы можете увидеть, как эти цифры выглядят на самом деле.
Пользователь превратил свои Apple Watch в волшебную палочку. Он создал приложение, которое позволяет управлять умным домом жестами и заклинаниями из «Гарри Поттера». Энтузиаст делает движение запястьем, словно машет палочкой, и произносит заклинание. Часы распознают одновременно жест и голосовую команду, после чего запускается нужное действие через HomeKit. Например, если сказать Lumos и правильно взмахнуть рукой, в доме включится свет. Команда Nox, наоборот, выключит освещение. К заклинанию можно привязать практически разные действия: открытие умного замка, изменение температуры, включение музыки. В основе лежат датчики, которые уже есть в Apple Watch: акселерометр и гироскоп отвечают за распознавание движения, а микрофон за голосовую команду. После этого приложение запускает соответствующий шорткат в HomeKit.
Разбор 100+ вопросов с собеседований Rust Полезный реподля подготовки к собеседованиям
Rust Interview Questions - это подборка вопросов, ответов и практических задач по Rust для тех, кто готовится к техническому интервью или хочет проверить, насколько хорошо понимает язык.
Внутри есть материалы по ключевым темам Rust:
ownership и move-семантика
borrowing и ссылки
lifetimes
traits и generics
Option и Result
обработка ошибок
память и безопасность
практические задачи с кодом
ответы и разборы
Rust нельзя нормально выучить только по синтаксису. Нужно понимать, почему borrow checker ругается, как работает владение, где появляются lifetime-ограничения и чем Rust отличается от языков с GC.
Этот репозиторий как раз про это: короткие вопросы, практические проверки и постепенное прокачивание Rust-мышления.
Подойдёт начинающим, которые уже знают базу, и разработчикам, которые хотят освежить Rust перед интервью.
Синхронный просмотр видео онлайн: почему screen share архитектурно плохое решение и как это исправить
Задача на первый взгляд простая: двое в разных локациях хотят смотреть одно видео синхронно. На практике большинство берёт первое что под рукой (screen share) и получает предсказуемо плохой результат. Разберём что происходит под капотом у каждого подхода.
Screen share
Discord, Zoom, Telegram используют WebRTC или собственные протоколы. Поток с дисплея захватывается, кодируется (VP8/VP9 или H.264 с агрессивным битрейтом для экономии полосы), передаётся через TURN/STUN-сервер, декодируется у получателя. Качество деградирует на каждом этапе, это следствие архитектуры, не баг. Задержка от 500 мс до 3 секунд в зависимости от условий. Только инициатор получает оригинальный видеопоток.
Веб-сервисы (Watch2Gether, WParty)
Видео либо проксируется через их серверы, либо используется embed API платформы. В случае YouTube: iframe с postMessage API для управления. Качество ограничено их инфраструктурой. Российские платформы (Кинопоиск, RuTube, Иви) через embed не работают или работают с серьёзными ограничениями.
Синхронизация состояния плеера
Принципиально другой подход. Расширение не трогает видеопоток. Оно встраивается в страницу, перехватывает события нативного плеера (play, pause, seeked, timeupdate) через MutationObserver или прямую инъекцию в DOM, и транслирует их участникам комнаты через WebSocket. Каждый участник грузит видео напрямую с CDN платформы. Синхронизируется только управление, не контент.
TandemParty работает по этой схеме. Поддержка: Кинопоиск, YouTube, ВК Видео, RuTube, Иви. Задержка синхронизации команд в пределах сетевого RTT. Из нестандартного: QR-пульт, WebSocket-сессия позволяет телефону выступать вторым контроллером плеера после сканирования QR-кода с экрана.
Техническая статья про устройство синхронизации изнутри есть в блоге: tandemparty.ru/blog
Почему у Bitcoin несколько типов адресов и в чём их отличие
Большинство пользователей просто копируют Bitcoin-адрес и отправляют средства, не особо задумываясь, почему одни адреса начинаются на 1A1zP1..., другие на 3J98t1..., а третьи выглядят как длинный набор символов вроде bc1qw508....
На практике это не “разные виды биткоина”, а результат эволюции самой сети Bitcoin. Каждый новый формат адресов появлялся как попытка решить конкретные проблемы: высокие комиссии, ограниченную пропускную способность, сложность транзакций или недостаточную эффективность сети.
Самые старые Bitcoin-адреса - это Legacy-адреса. Обычно они начинаются на 1. Это первый массовый формат адресов в сети Bitcoin, который использовался ещё задолго до появления современных обновлений. Главный минус таких адресов сегодня - менее эффективная структура транзакций, из-за чего комиссии обычно выше.
Позже появился формат SegWit. Чаще всего такие адреса начинаются на 3. Его главная задача была довольно практичной: уменьшить размер транзакций и снизить нагрузку на сеть. Благодаря этому комиссии стали ниже, а сама сеть - эффективнее. По сути, SegWit стал одним из самых важных обновлений Bitcoin за последние годы.
Следующий этап - Native SegWit или Bech32. Именно эти адреса начинаются на bc1. Сейчас они считаются более современным вариантом для обычных переводов. Такие адреса занимают меньше места в блоке, ещё сильнее снижают комиссии и лучше подходят для современной инфраструктуры Bitcoin. Именно поэтому всё больше кошельков и сервисов по умолчанию используют формат bc1.
Но эволюция на этом не остановилась. После обновления Taproot в сети появились и новые типы адресов bc1p..., которые уже связаны не только с экономией комиссий, но и с более сложными возможностями сети. Например, Taproot улучшил эффективность multisig-транзакций, частично повысил приватность некоторых сценариев и подготовил основу для более гибких механизмов работы Bitcoin в будущем.
Из-за этого сегодня в сети одновременно существуют сразу несколько форматов адресов. Старые варианты никуда не исчезли, потому что Bitcoin очень осторожно относится к совместимости: сеть должна продолжать работать даже с кошельками и сервисами прошлых поколений.
Именно поэтому один пользователь может отправлять BTC на адрес формата 1A1zP1..., другой на 3J98t1..., а третий на bc1qw508... - и все они всё равно работают внутри одной сети Bitcoin.
Если упростить, разные типы Bitcoin-адресов - это не хаос и не путаница, а следствие того, как сама сеть постепенно развивалась, пытаясь сделать транзакции дешевле, эффективнее и технологически гибче.
