Нейронки умеют рисовать не только пляшущих котов с баянами на деревенской свадьбе. Еще они могут творить настоящее искусство. И пять отобранных примеров в статье красноречиво это подтверждают.
В апреле 2026 года Canonical раскрыла 44 CVE в uutils. Это переписанная на Rust версия GNU coreutils, которая в Ubuntu идёт по умолчанию с 25.10. Раскрытие пришло из внешнего аудита, заказанного перед релизом 26.04 LTS. Большую часть уязвимостей нашли обычным ревью кода. Ни borrow checker, ни проверки clippy, ни cargo audit не поймали ни одной.
Этот аудит, пожалуй, самый чёткий из существующих примеров того, что Rust ловит, а что нет. Самый внятный разбор списка сделал Маттиас Эндлер в посте «Bugs Rust Won’t Catch» от 29 апреля. Эндлер ведёт консалтинг corrode и подкаст Rust in Production; недавно у него в гостях был Джон Сигер, вице-президент по инженерии в Canonical. Пост построен как разбор того самого раскрытия: 44 CVE распределены по восьми категориям; к большинству приложен git diff фикса.
Ниже разберу каркас Эндлера и добавлю два аргумента сверху. Первый: один из мейнтейнеров GNU coreutils в HN-треде показал бенчмарк, на котором рекомендованный Эндлером фикс не выживает. Второй: структурный аргумент про то, что 40 лет наслоённых POSIX-шрамов делают с любой переписью, независимо от языка.
В ответах на вопросы по статье про Яндекс Сплит напридумывал такого, что аж стыдно. Но удалять не буду и распишу подробно, как работает Сплит и Супер Сплит, и чем они отличаются.
В моей старой статье про устройство BNPL (сентябрь 2022, «Оплата долями или при чём здесь исламский банкинг») основной тезис был такой: BNPL — это обходной путь регулирования. Сервис рассрочки делает ООО, не подпадающее под 353-ФЗ, не передающее данные в БКИ, и зарабатывает на комиссии магазина. Государство закрывало глаза на существование схемы, пока сегмент не перестал быть маленьким.
В 2025 году рынок BNPL в России дорос до 940 млрд рублей (данные «Долями» от Т-Банка), за первое полугодие удвоился. Так появился 283-ФЗ от 31.07.2025 «О деятельности по предоставлению сервиса рассрочки», вступивший в силу 1 апреля 2026. Что в законе: реестр операторов, лимит 50 000 ₽, срок до 6 месяцев (с 2028 — до 4), запрет скрытых комиссий, передача в БКИ при долге свыше лимита, неустойка не более 20% годовых (потолок — оператор может взять и ноль).
Интересен кейс Яндекса. Ранее у них был один «Сплит» с возможностью апгрейда до «Супер Сплита». Сейчас это уже два юридически и экономически разных продукта в одном интерфейсе под одним брендом. Разберу, как они устроены, чем отличаются и почему такая конструкция возникла.
Свежепоставленный мониторинг на DGX Spark. Открываю NVIDIA‑дашборд в Grafana — половина memory‑панелей пустые, прямые линии по нулю. Сначала кажется, что что‑то не настроил. Через полчаса доходит: это не у меня сломалось, это NVML на GB10 так работает.
Это та область, где на GB10 половина стандартного observability‑стека просто не работает: NVML отдаёт [N/A] на memory.used и memory.total, dcgm‑exporter не ставится, nvtop в memory‑колонке показывает пустоту. В Grafana NVIDIA‑дашборды по умолчанию выглядят так, будто GPU вообще нет — и это не очевидно, потому что Grafana при отсутствии данных не кричит, а молча рисует ровную линию по нулю.
Статья — про то, как я это место обошёл и что в итоге увидел в Grafana. Трёхуровневая схема: textfile collector для базовых метрик, per‑container attribution через docker top + nvidia-smi, и CLI‑фоллбэк на /proc/meminfo, который оказался полезен не только на Spark, но и на других Linux‑системах с единой памятью (unified memory) — AMD Strix Halo и подобные.
Типа предупреждение:
Далее идет нейрослоп и полет больной фантазии. Вы читаете его на свой страх и риск.
Документ строится как рабочая модель, основанная на наблюдаемых трендах. Реальность пройдёт по своей траектории, и она почти гарантированно будет отличаться от прогноза в деталях — но главные структурные вехи обоснованы достаточно, чтобы быть рабочей основой для размышлений и решений.
Если ваш ИИ-агент при каждом вопросе начинает grep-ом по всему проекту — у меня есть для вас одна штука. SocratiCode — это MCP-сервер, который индексирует кодовую базу через Qdrant и даёт агенту нормальный поиск вместо построчного чтения. Разобрал, как он устроен внутри, потестировал на нашем монорепе и сравнил с обычным режимом Claude Code
Индустрия автономных мультиагентных систем (MAS) сейчас на подъеме. В начале 2026 года фреймворк OpenClaw получил сотни тысяч звезд на GitHub и задал стандарт: локальный Gateway, фоновый процесс, легко подключаемая система скиллов и интеграция с мессенджерами - «LLM с руками», классический ReAct-цикл (Reason + Act), умный ассистент.
Но попытка приспособить OpenClaw и его аналоги под сложные инженерные задачи с большим контекстом и высокой ценой ошибки упирается в архитектурные ограничения. IMHO, можно выделить четыре проблемы, из-за которых современные MAS сыплются при масштабировании:
Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF-полям без индексов, лишние JOIN, неявный LIKE в ORM, N+1-запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест.
В статье разбираем, как подойти к проблеме системно: включить slow query log, прочитать EXPLAIN, найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.
Nonce Observatory: как превратить цифровые подписи в систему наблюдаемых nonce-инвариантов
Большинство историй про ECDSA/Schnorr nonce звучит одинаково: “повторили nonce — потеряли ключ”. Но реальные дефекты часто тоньше: короткие nonce, частичная утечка битов, смещение, recurrence, window-locality, prefix-семейства, ошибки в multi-signature контексте.
Мы собрали исследовательскую систему Nonce Observatory — не “кнопку взлома”, а forensic framework для анализа слабых nonce-структур в:
ECDSA • Schnorr/BIP340 • MuSig2/BIP327
Что внутри:
protocol-valid bridges affine hidden-nonce families HNP / lattice routes Q-LLL + fplll same-case checks AI sidecar на gpt-oss-20b-TurboQuant-MLX-8bit exact evidence / redaction / claim boundaries full-system audit
Главный принцип системы:
сигнал ≠ восстановление; кандидат ≠ приватный ключ; claim принимается только если d·G == public key.
В статье расскажу:
— что такое HNP и зачем он нужен для ECDSA; — как подписи превращаются в affine nonce geometry; — почему BIP340 и MuSig2 требуют protocol bridge; — как Q-LLL используется как lattice backend, а не “магический oracle”; — зачем нужен AI sidecar и почему AI не имеет права принимать d; — как мы дошли до full-range controlled HNP recovery без nonce brute force; — почему full-system audit важнее красивого demo.
Это статья не про “сломать Bitcoin”. Это статья про инженерную дисциплину в криптографической форензике: наблюдаемость, воспроизводимость, проверяемость и честные границы заявлений.
Привет, Хабр. Меня зовут Алексей, я C#-разработчик. В этой статье хочу рассказать о своём дипломном проекте очень запавшем мне в душу, который я делал на тему обработки изображений, GIS и дистанционного зондирования Земли. Даже спустя годы мне интересна данная тема и она по-прежнему остаётся очень перспективной в различных отраслях.
Идея была в том, чтобы собрать небольшое настольное приложение, которое умеет работать с реальными спутниковыми данными: Landsat 8, Sentinel-2 и AVIRIS. То есть открывать не готовую RGB-картинку, а набор спектральных каналов, собирать из них естественные и псевдоцветные изображения, считать растровые индексы, выделять эталоны прямо на снимке, классифицировать пиксели, сегментировать изображение и пробовать более исследовательские вещи вроде EMD-разложения.
В итоге получилась учебно-исследовательская программа, но с полным рабочим циклом: от чтения спутникового архива до сохранения информативного результата обработки. Ниже расскажу, зачем вообще нужны такие снимки, какие особенности есть у разных спутниковых данных, что делает приложение и какие алгоритмы оказались самыми интересными.
Всем привет!
Многие не пишут про это (или стесняются или что, не знаю). А я напишу про себя, как меня развели сегодня в максе.
Я живу поселке и веду пару чатов в телеге для всего поселка (это для понимания, как я обложался).
Диалог в максе :
Если вы за последние полгода хоть раз заходили в интернет, то наверняка натыкались на посты в духе: «За выходные навайбкодил B2B SAAS ULTRA SUPER AI APP». Как-то незаметно мы оказались в мире, где сидишь и смотришь, как ИИ-агент сам ползает по папкам на диске, запускает тесты, падает с ошибкой, ругается на свои же логи (или тебя) и молча открывает пулреквест.
Предлагаю отмотать время немного назад и посмотреть, как мы вообще докатились до жизни такой. Под катом краткая историческая ретроспектива того, как ИИ-кодинг прошёл путь от умного T9 до мультиагентных систем, и иллюстрация того, почему главный навык синьора сегодня — это умение вовремя написать: «Я ЖЕ СКАЗАЛ, НЕ ДОПУСКАЙ ОШИБОК, ПОДУМАЙ ЕЩЁ РАЗ И СДЕЛАЙ НОРМАЛЬНО».
Прежде чем начать свой рассказ, представлюсь. Я Сергей Чекмарёв, AI Product Manager и программный автор курса по вайбкодингу в Практикуме. Специализируюсь на автоматизации процессов и создании продуктов на базе искусственного интеллекта.
Внедрили MES, а производство как работало, так и работает? Интегратор обещал прозрачность, а руководство предприятия получило гору отписок в духе «некогда сканировать»? Разбираемся, что с этим делать.
Передовые модели сейчас действительно хорошо пишут код — лучше, чем справляются с большинством других задач. Работа с агентами ощущается как взгляд из будущего: полигон для проверки того, насколько далеко можно зайти с агентными возможностями. Это заряжает, даёт результат и при этом — откровенно странно ощущается.
Я веду список советов по агентному кодингу: правила и ориентиры для тех, кто только начинает работать с Codex, Claude Code, Pi или любым другим агентом. Каждый пункт — обобщённая рекомендация, применимая к агентному программированию в целом. Хочется, чтобы уроки оставались актуальными по мере того, как улучшаются модели и инструменты.
Ниже — текущий список: 10 уроков агентного кодинга. Десять — красивое круглое число, хороший повод опубликовать.
Исследование, опубликованное в журнале Frontiers in Behavioral Neuroscience, является одним из первых контролируемых экспериментов на людях, в котором подтверждённое воздействие инфразвука сопоставляется как с психологическими самоотчётами, так и с конкретным физиологическим маркером — уровнем кортизола в слюне, гормона, который мы ассоциируем со стрессом. Результаты получились, можно сказать, тревожными.
Инфразвук — это звуковые волны с частотой ниже примерно 20 Гц, что соответствует нижней границе диапазона, улавливаемого человеческим ухом в обычных условиях. Он возникает в результате штормов, вулканической активности, тектонических толчков в недрах земной коры и, что самое важное, в результате обыденного механического «сердцебиения» городов: стареющих труб, систем отопления, вентиляции и кондиционирования, дорожного движения, промышленного оборудования. «Инфразвук повсеместно присутствует в повседневной среде, возникая вблизи вентиляционных систем, дорожного движения и промышленного оборудования», — говорит Родни Шмальц, старший автор и профессор Университета Макьюэна. В большинстве случаев мы проходим сквозь него, не замечая. Вопрос, на который команда хотела ответить, заключался в том, действительно ли попадание в зону его действия оказывает на нас какое-то воздействие, регистрируется ли эта частота где-то ниже уровня сознания, в той области, которую мы не можем легко определить.
Привет, меня зовут Николай, я 23 года в DevOps, последние пару-тройку месяцев копаюсь в архитектуре AI-агента (Hermes Agent)
В предыдущих двух статьях я разбирал, почему AI-агенты сходят с ума на длинных сессиях (сжатие контекста) и почему Chain-of-Thought это пост-хок нарратив, а не трассировка мышления. Статьи неплохо зашли, но в комментариях меня справедливо пропесочили: "нейрослоп с характерными эпитетами, очередной набор запросов к ИИ". Ну и по делу в принципе. Пишем руками, нудное это дело если честно, все равно вычитку в агента отдал в итоге.
И сегодня я расскажу про два инструмента, которые использую постоянно: Premortem и Prism. Не в теории, а на моём собственном опыте.
Prism это не моё изобретение. Это форк из Cranot/super-hermes, доработанный под мои задачи. В оригинале — пять независимых скилов структурного анализа. Premortem — вообще классика, из книги Klein «The Power of Intuition» и военной аналитики. Но я их доработал так, что это не просто "очередная методология для митапов", а работающий pipeline, который находит баги архитектуры.
Всем привет! На связи Ирина Маркова и подкаст «До нас дошло». Мы (Иннокентий Солнцев, Артем Ковальчук, Марат Сибгатулин и я) делаем небольшие подкасты про историю связи. Когда я делала цикл выпусков про историю развития телеграфа, у меня скопилось большое количество ссылок и заметок на эту тему, плюс сами сценарии выпусков содержат много информации. И вот ребятам пришла идея объединить всё в большой текст, помимо уже записанных выпусков. Ну кто я такая, чтобы им отказать?
С названием статьи долго думать не пришлось. На хабре очень много статей с названием «Краткая история телеграфа» или «История телеграфа в кратком изложении» и так далее. У меня получилось расписать основные этапы немного подробнее.
О чем будет эта статья? Она раскроет основные вехи развития телеграфа: что было до телеграфа, первые оптические системы, электрохимические системы, первые электромагнитные телеграфы и их вариации, мультиплексный телеграф Бодо и венец этого развития — телетайп.
Итак, мы начинаем!
Собрали самые интересные CVE апреля в нашу традиционную подборку. Критическими уязвимостями под RCE в прошлом месяце отметились Microsoft Azure и Bing, а также Mozilla Firefox и Thunderbird.
Месяц не обошёлся и без критических уязвимостей в продуктах от Cisco: в IMC и SSM On-Prem исправили обход аутентификации и произвольные команды с root-правами, соответственно. Критические CVE также закрыли в OpenSSL, JavaScript-движке в процессорах Samsung Exynos и продуктах от SAP. Обо всём этом и других ключевых уязвимостях апреля читайте под катом!
Продолжаем разбирать HikariCP: как выбирать размер пула, что учитывать в Kubernetes и при нескольких сервисах, почему большой maximumPoolSize не всегда помогает, какие настройки стоит пересмотреть перед продом и какие ошибки чаще всего приводят к проблемам с базой.
С типом float рано или поздно сталкивается почти любой разработчик. Сначала все выглядит просто. Есть float32, есть float64, можно хранить дробные числа, делить, умножать, считать проценты, средние значения, коэффициенты и что угодно еще. Кажется, что это просто «числа с точкой». Но именно здесь у многих начинаются странные баги.
Почему 0.1 + 0.2 != 0.3? Почему после серии вычислений число внезапно становится 9.99999999997 вместо 10? Почему сравнение двух значений с float64 иногда работает, а иногда ломает логику? Почему в деньгах float почти всегда плохая идея? И почему даже корректная формула может давать нестабильный результат? Проблема не в Go. Проблема в том, что float устроен не так, как его часто себе представляют. Это не «точное дробное число», а приближенное представление вещественных чисел в памяти компьютера.
В этой статье разберем, как устроен float в Go, где он полезен, где опасен, какие ошибки встречаются чаще всего и какие практики помогают не ловить неприятные сюрпризы в проде.