Новое исследование представило метод, использующий классические вычислительные мощности для снижения текущего уровня безопасности RSA до неприемлемо низкого предела. Применение атаки к устаревшим 1024-битным ключам заняло всего несколько месяцев на академическом кластере процессоров.
Когда пишут программу HelloWorld на C, обычно выводят текст “Hello, World!”. Но когда программа пишется для микроконтроллера, часто ограничиваются миганием светодиода, особенно для микроконтроллеров семейства STM32.
В статье я разберу, как можно вывести “Hello World” в программе для микроконтроллеров этого семейства.
В начале этого года я был убеждён, что планирование станет самой важной частью разработки программного обеспечения с помощью ИИ.
Эта идея захватила меня настолько, что я построил и запустил целое десктопное приложение для разработки вокруг неё. Nuanced появился из наблюдения: ИИ радикально увеличил скорость и объём генерации кода, но интерфейсы, необходимые для поддержки этого нового темпа работы, не успевали за ним.
Мы сначала сделали внутренний образовательный проект, а потом получили образовательную лицензию.
Логика была такая:
— Работодатель опасается учить сотрудников, потому что после обучения они могут уйти в другую компанию на зарплату повыше;
— Но ядерка — сфера особенная. У нас долгий онбординг: от полугода для рядового айтишника, год — для архитекторов и девопсов. При этом он типовой для многих наборов навыков;
— Нам выгоднее растить свои компетенции «дома» — повышать квалификацию или давать новый стек тем, кто уже знаком с нормами ИБ, регуляторикой и внутренними системами.
Поэтому мы в Гринатоме — это крупнейший ИТ-интегратор внутри Росатома — решили сделать свою школу айтишников.
И мы справились. Сейчас даже выдаём выпускникам документы о повышении квалификации и переквалификации.
Рассказываю, как это было.
В процессе подготовки к соревнованиям по системному программированию на C++ я начал заново изучать CMake, потому что Cargo сильно меня избаловал. При этом я заметил в туториале интересное утверждение:
Зачастую правильным оказывается написать для решения задачи инструмент на языке программирования общего назначения и научить CMake вызывать этот инструмент в процессе сборки. На языке CMake уже создавались утилиты для генерации кода и криптографических подписей и даже трассировщики лучей, но такая практика не рекомендуется.
Я раньше писал трассировщик лучей и переписывал его под GPU, поэтому это заявление привлекло моё внимание и заставило задуматься, на каком же ещё языке лучше писать такой трассировщик.
Для последней версии я писал код, почти не связанный с базовыми алгоритмами и в основном зависевший от довольно сложного набора API. Поэтому я выбрал самый простой из известных мне языков — Brainfuck, ведь простота языка очевидным образом приводит к созданию простой кодовой базы. На самом деле, кодовые базы на BF обычно состоят всего из нескольких строк. Кроме того, комментарий Урбана Мюллера в README заставил меня написать контрпример.
Код выложен на Github.
Привет, Хабр. Меня зовут Алексей Зайцев, я системный архитектор в отделе проектирования телеком-платформ, а это шестая статья цикла про разработку базовых станций в YADRO.
За последние пару лет наши платы BBU прошли стадии EVT (Engineering Validation Test), DVT (Design Validation Test), PVT (Production Validation Test) и наконец MP (Mass Production). К этому моменту мы выпустили уже несколько тысяч плат, а эксплуатация базовых станций YADRO сейчас охватывает 37 регионов России. Но этому результату предшествовал тяжелый и кропотливый этап — разработка собственных тестовых стендов, на которых мы могли бы проверить каждую плату и модуль. Почему не блок целиком?
Цифровой блок обработки базовой станции (BBU, Baseband Unit) поставляется операторам сотовой связи модулями, а не в виде единого полностью укомплектованного шасси. Функционально тестировать BBU как единое готовое устройство на заводе перед отгрузкой нецелесообразно — каждую плату мы проверяем автономно и независимо. Об этом сегодня и поговорим.
Во время уборки зерно в комбайне проходит долгий путь: от жатки через барабан, решётку и домолот до зернового элеватора и бункера. Весь этот путь нужен не просто так, а для того, чтобы максимально очистить зерно и при этом сохранить его целостность, ведь от этого напрямую зависит цена продажи. Но узнать, насколько хорошо прошла очистка, обычно можно только постфактум: на элеваторе или в лаборатории, когда повлиять на результат уборки уже нельзя.
Рассказываю, как мы создали систему Crop Control, которая доустанавливается на комбайн (даже если раньше на нём не было никакой автоматики) и позволяет мониторить качество и количество зерна прямо во время движения. Мониторинг количества нужен, чтобы понимать, сколько урожая собрано с конкретного поля: урожайность - одна из ключевых метрик оценки продуктивности уборочной кампании в целом. А мониторинг качества нужен для того, чтобы вовремя повлиять на собираемую продукцию, например скорректировать настройки комбайна, и не дать испортить уже намолоченное зерно.
Привет, Хабр. На связи Николай Карасов, ведущий разработчик отдела рекомендаций контентных сервисов в AI VK. Наша команда отвечает за рекомендации в Ленте ВКонтакте.
Перед нами стояла цель — развить внутри ВКонтакте новый пользовательский сценарий: человек приходит за контентом, видит у автора интересный ему товар и переходит к покупке прямо из социальной сети. Так в Ленте появился новый тип объекта — товарный пост. Первым партнёром в этом сценарии стал Ozon. Дальше речь пойдёт именно про товарные посты авторов в рамках реферальной программы Ozon, а не про любые публикации с товарами.
Было понятно, что обычный рекомендер для такого сценария не подходит. В итоге мы построили внутри Ленты отдельный товарный контур: со своими логированием, селекторами кандидатов, моделью ранжирования и выделенной квотой в финальной выдаче. Про это и расскажу.
Привет, Хаброжители!
Встречаем осень с хорошими новостями — в нашем интернет-магазине только что началась новая распродажа!
У меня есть коллекция музыки, которой нет ни в одном стриминге: FLAC, японские альбомы, редкие релизы. Слушать её хотелось так же удобно, как Spotify, с телефона и компьютера, с текстами и итогами года. Готовые решения закрывали задачу по кусочкам, поэтому я написал своё: Nami — плеер для Android, Windows и Linux и собственный сервер на Rust. Внутри: синхронизация между устройствами через одну SQL‑таблицу вместо девяти, караоке‑тексты с выравниванием по словам нейросетью прямо на телефоне, фуригана и ромадзи для японских песен, bit‑perfect‑вывод на USB‑ЦАП и сервер, который занимает 69 МБ памяти.
Представьте двух спортсменов: футболиста и гонщика «Формулы-1». Футболист может носиться по полю с невероятной скоростью, но всё же двигаться в пределах человеческих возможностей. Он может быть быстрее всех и мгновенно менять направление, однако всё происходит в темпе, за которым человеческий мозг способен уследить.
А теперь представьте гонщика, который едет по прямой примерно 350 км/ч, а в поворотах — около 290. Ни одно сухопутное животное, живое или вымершее, никогда не бегало даже вполовину так быстро. Скорость попросту слишком велика, чтобы обычный человеческий мозг успевал обрабатывать происходящее. Так как же им это удаётся? Как человеческий разум справляется со спортом, который развивается быстрее, чем мозг способен за ним следить?
«Существует предел, своего рода физиологический предел, — говорит Отто Лаппи, старший преподаватель Хельсинкского университета. — Но есть гораздо меньше ограничений на то, сколько хитроумных механизмов способен выстроить мозг: изучить окружающую среду и понять, что именно мне сейчас нужно сделать, чтобы не убиться».
Веб-агент сообщил «готово» — а сделал ли? На живых сайтах это не проверить: контент меняется, а судить приходится либо по словам самого агента, либо через LLM-судью, который тоже ошибается. Мы выпускаем WebPageBench — открытый бенчмарк из 152 задач на шести имитациях популярных российских сервисов (от покупок на маркетплейсах до бронирования билетов на поезд). В комплекте локальная среда, в которой любой агент запускается одной командой, и публичный рейтинг, в котором представлено 24 связки «модель + обвязка», а по результатом которого видно, что агенты зачастую сильно завышают свои результаты.
Код и задачи лежат в репозитории, рейтинговая таблица — на Hugging Face, препринт статьи — на arXiv. Ниже расскажем, зачем мы это сделали, как бенчмарк устроен, что уже видно по результатам и как запустить его у себя.
Привет, Хабр!
Я часто вам рассказываю, как HTML и CSS помогают улучшить пользовательский опыт в наших веб-интерфейсах. Мне это наскучило. Сегодня я хочу поговорить с вами о практиках, которые заставляют пользователей очень сильно ругать разработчиков.
Мы рассмотрим примеры, когда только использование HTML и CSS может привести к замешательству людей. Многие же думают, что эти технологии безопасны и не могут принести вреда. Вот и проверим это.
Давайте посмотрим, что я вам подготовил.
В сентябре 2026-го по миру разлетелись заголовки о том, что ученые смогли оцифровать мозг живого существа — мушки дрозофилы. Карту ее «мозга» выложили в общий доступ, и энтузиасты очень быстро превратили ее в игрушку: научили играть в Doom, Minecraft, собирать кубик Рубика и всячески издеваться и заставлять работать. От экспериментов с мухой не удержались и в MWS, о чем расскажу ниже.
Явление бесчисленных эксплуатаций цифровой мухи именовали флайслопом (FlySlop). Но проблема не в этом — стараниями журналистов многие люди решили, что мы действительно научились полностью переносить сознание в компьютер, и новая серия «Черного зеркала» уже не за горами. На самом деле не все так просто: ученым удалось только скопировать один из уровней работы мозга — карту нервной системы с нейронами и синаптическими соединениями. Но до полной функции сознания им еще очень и очень далеко.
Попробуем разобраться, на что действительно способна цифромуха, чего смогли добиться исследователи и случился ли прорыв в нейробиологии…
Когда я впервые начала использовать AI в работе, сценарий был довольно стандартным: открыть чат, вставить текст, сформулировать запрос, получить ответ — это удобно, но возможности довольно быстро упираются в потолок. Модель не знает контекст ваших проектов, не видит документацию и код, не понимает принятые в команде правила и каждый раз требует заново объяснять, что именно вы от нее хотите.
Следующим моим шагом стало собрать вокруг модели рабочую среду. В моем случае такой средой стал OpenCode. Хотя этот агент в первую очередь ассоциируется с разработкой, его можно использовать гораздо шире. По сути, это оболочка, в которой LLM получает доступ к файлам, инструкциям, локальным инструментам, API и MCP-серверам, а затем использует все это для решения задач конкретного пользователя.
Привет, Хабр! Я Арина, аналитик в Selectel. В этой статье я покажу не столько «как установить OpenCode», сколько как организовать вокруг него рабочее пространство, чтобы агент выдавал более стабильный результат и действительно снимал часть рутинной работы.
Привет! Меня зовут Александр Каненков, я backend-разработчик в компании Домклик.
После перевода сервиса со второго Spring Boot на третий (а у кого-то уже и на четвёртый) мы с командой заметили следующую картину: HTTP-запрос журналируется с traceId, цепочка собирается в трейсе, но стоит сработать задаче Quartz — в журналах worker-потока гордо красуется [NoTrace, NoSpan]. Задача исполняется «в никуда» — без единого идентификатора, вне какого-либо трейса, и связать её с запросом, который её запланировал, невозможно.
Давайте разберём по шагам, почему это случилось и как починить так, чтобы работало и с RAM (in-memory), и с JDBC job store.
Я расскажу и расставлю акценты, которые гораздо важнее красивого лендинга, языка программирования, модной архитектуры и красивого кода. Акценты, которые позволят тебе раскрутить сервис и занять стабильное место на рынке.
Си отлично работает на микроконтроллерах и никуда не исчезает. Но часть правил, которые в Си держатся на архитектуре проекта и дисциплине разработчика, в Rust можно выразить так, чтобы их проверял компилятор.
Разберём это на DMA, владении периферией, состояниях GPIO, прерываниях и unsafe — без попытки доказать, что Rust должен заменить Си.
В первые месяцы моей работы журналистом, пишущим о физике, почти десять лет назад я постоянно натыкался на странную последовательность символов: AdS/CFT. Она меня изрядно пугала, и я решил просто не обращать на неё внимания.
Но долго прятать голову в песок не получилось. Вскоре я узнал, что эти символы обозначают удивительную связь между, казалось бы, несовместимыми мирами гравитации и квантовой механики. А ещё более странным образом это «соответствие анти‑де‑ситтеровского пространства и конформной теории поля» предполагает, что гравитация устраняет различие между объёмом и площадью. Более общая идея получила название голографического принципа, и теперь мне кажется, что это самое глубокое предположение в теоретической физике за последние 30 лет.
Физики‑теоретики склонны голосовать ногами, и AdS/CFT вызвало настоящий массовый забег. Три основополагающие статьи по этой теме, опубликованные в конце 1990-х годов, получили десятки тысяч цитирований и с огромным отрывом стали самыми цитируемыми работами по теоретической физике цифровой эпохи. В моих разговорах с физиками, изучающими голографию, они часто казались искренне ошеломлёнными и прибегали к словам вроде «волшебство» и «чудо», чтобы её описать. И, конечно, не помешало и то, что голография привела к практически общепринятому ответу на самую знаменитую загадку физики: вопреки тому, что утверждал Стивен Хокинг, чёрные дыры не являются тюрьмами, из которых ничто не может выбраться.
Но даже после того, как я написал о множестве открытий в области голографии и провёл бесчисленное количество разговоров с работающими над ней физиками, ощущение путаницы не исчезло. Я слышал, что голография предполагает, будто гравитация и квантовая механика — это одно и то же, и что пространство может быть иллюзией. Я также слышал, как голографию описывали одновременно и как математический факт, и как спекулятивный полёт фантазии. Поэтому я решил сопоставить эти дикие идеи и выяснить, что именно голографический принцип говорит о нашей Вселенной.
Привет!
Заверните обычный File в структуру из одного поля и пробросьте чтение внутрь. Пара строк, логика не поменялась. А теперь скопируйте через io::copy файл на 64 мегабайта: голый File справлялся за два системных вызова, обёртка сделает больше шестнадцати тысяч.
Ошибки в коде нет, вы просто выпали из специализации, которой в стабильном Rust официально не существует. Зато в стандартной библиотеке на ней висит больше сотни функций, и такая фича там не одна: даже NonNull хранит адрес в типе, который на stable объявить нельзя.
Чем глубже копаешь, тем веселее. Та же специализация ускоряет collect и умеет заставить код без единого unsafe читать освобождённую память, а итератор, написанный как обычная функция, превращается в идеальный ассемблер и почему-то отказывается векторизоваться. Материала набралось на четыре-пять статей, это первая, и в ней пять фич: gen-блоки, pattern types, специализация, become и #[loop_match].
Это вторая часть материала про ИИ-агентов в корпоративном контуре для блога ЛАНИТ. В первой речь шла о том, как ограничить агента технически, какие полномочия ему давать, как разделять доверенные и недоверенные источники, что логировать и как тестировать систему до запуска. Здесь – о следующем вопросе. Что происходит, если ограничения все-таки не сработали, агент сделал что-то не то, а последствия уже наступили?
Я не юрист, и этот текст не стоит воспринимать как правовую консультацию. Это взгляд человека, который проектирует и внедряет такие системы и регулярно сталкивается с ситуациями, где техническое решение внезапно становится вопросом ответственности, доказательств и полномочий. Конкретные юридические решения в реальном проекте нужно обсуждать с профильными специалистами.
Главная мысль статьи довольно простая – ИИ-агент может получать данные, принимать промежуточные решения, формировать документы, вызывать инструменты и инициировать действия, но самостоятельным носителем ответственности он от этого не становится. Поэтому у любого значимого действия должна оставаться восстанавливаемая цепочка: кто дал агенту полномочия, от чьего имени он действовал, кто должен был проверить результат и в каком состоянии находилась система в момент инцидента.