Все потоки

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

В моей старой статье про устройство 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, где он полезен, где опасен, какие ошибки встречаются чаще всего и какие практики помогают не ловить неприятные сюрпризы в проде.

using в C# выглядит как универсальная страховка от утечек ресурсов, пока объект живёт строго внутри одного метода. Но стоит вернуть его наружу, передать в фоновую задачу, положить в коллекцию или доверить DI‑контейнеру — и привычное правило начинает работать против вас.

В статье разберём типичные сценарии, где IDisposable превращается в источник нестабильных багов: закрытые раньше времени соединения, гонки с Task.Run, утечки обработчиков и тот самый HttpClient, который лучше не создавать на каждый запрос.

В предыдущей статье (как отдавать лиды из Next.js в 1С Битрикс) я показывал outbound‑интеграцию: сайт пишет лид к себе в PostgreSQL, через after() отдаёт его в Битрикс, в строку лида подкладывает bitrix_id. Архитектура работает, пока Битрикс один.

Но в реальной жизни Битрикс редко остаётся один. Сценарии, в которых нужна полноценная миграция между инстансами, я ловил на проектах четыре раза за последний год: