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

Но. Смотрите, что произойдет, как только вы выйдете из квартиры.

Вы прикладываете к домофону ключ-«таблетку» — и в этот момент, возможно, пользуетесь шиной 1-Wire, которая по своей топологии буквально шина. 

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

Вечером вы идете на концерт — и вся светотехника над сценой, сотни приборов, управляется по DMX512, который бегает поверх шинного интерфейса RS-485. 

Даже показания квартирного теплосчетчика снимаются по M-Bus — специализированной шине для счетчиков.

Звезда победила в офисах и дата-центрах. Но стоит выйти за пределы серверной — на завод, в цех, на подстанцию, в автомобиль, за кулисы концертного зала, квартиру — и выясняется, что там до сих пор правит бал старая добрая шина. Два провода, протянутые через весь объект, и десятки устройств, повисших на них параллельно, как белье на веревке.

Как же так вышло, в наш век современной и быстрой связи?

Начнем с простого. Вы скачали нейросеть, и теперь у вас на диске лежит файл на несколько гигабайт, внутри которого миллиарды чисел. Этот файл можно запустить и он будет делать всякие осмысленные штуки: писать текст, отличать котов от собак на фотографиях, переводить с китайского. То есть перед нами работающая программа. Только исходного кода к ней нет, и никогда не было.

Дальше в статье мы разберем идею, которая из этого же наблюдения и выросла. Она звучит так: а давайте напишем компилятор, который берет понятную человеку программу и превращает ее прямо в веса нейросети.

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

У меня в ~/.config/secretkeys/ лежит очень важный OAuth-токен. У вас на машине, скорее всего, тоже есть аналогичные штуки: ключи от облака, GitHub PAT в ~/.config/gh/, SSH-ключи в ~/.ssh/. И когда ИИ-агент запущен от имени моего пользователя, он видит все это по тем же путям, что и я. Не гипотетически может увидеть, а буквально читает и может распорядиться властью, данной ему, не самым лучшим образом, о чем я рассказывал в предыдущей статье. Поэтому я долго не пользовался агентами всерьез.

Больше всего меня пугали не риски промпт-инъекции или намеренной атаки. Давила постоянная тревожность: запущу агент не в той директории — он перепутает токены и сходит туда, куда не надо, либо снесет диск одной командой. Я делал отдельные виртуалки под каждый проект и они работали, но ели время и ресурсы. Хотелось иметь инструмент, которому можно доверять и который не потребует ставить дома серверную стойку под вычислительные ресурсы для виртуальных машин.

Несколько месяцев назад я нашел инструмент, который, как мне тогда показалось, отлично подойдет под мои запросы. Разбираю, что из этого вышло.

Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.

Привыкаешь к этому быстро. Нам кажется совершенно естественным тасовать эти типы между собой – уж слишком давно так делается по всей индустрии. Но стоит лишь чуток задуматься, и начинает прорезаться легкий когнитивный диссонанс: выходит, вся наша графика построена на наборах несовместимых между собой математических запчастей. Для одного действия нам нужен один тип данных, для второго – другой, а пересчитать простое столкновение луча со сферой или плоскостью без пятого велосипеда никак не получается. Вроде бы всё работает и даже неплохо работает… Но ощущение конструктора из костылей не отпускает.

И самое интересное заключается в том, что так было не обязательно.

В третьей и последней статье цикла о конечных полях мы завершаем путь от базовых понятий абстрактной алгебры к полям вида . Разберёмся, как строить поля вида и изоморфизм между полями одинакового порядка на примере полей и . Для наглядности также построим поле . Заодно посмотрим, как автоматизировать вычисления и эксперименты в конечных полях с помощью SageMath.

Во второй статье цикла о конечных полях продолжаем путь от базовых понятий абстрактной алгебры к полям вида . Разберёмся, чем отличаются кольца и поля, познакомимся с конечными полями и на практике построим поле . Заодно посмотрим, как автоматизировать такие вычисления и эксперименты с помощью SageMath.

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

Месяц назад начал делать собственный язык программирования Nova с Claude Code. За это время агенты автономно закрыли около трёхсот инженерных планов, написали около 120 тысяч строк Rust (компилятор, рантайм, кодоген), почти две тысячи проходящих тестов и собственную стандартную библиотеку на Nova. Один человек физически такой объём не вытянет — но и автономия даётся не бесплатно.

Рассказываю про четыре категории сбоев, которые встречаются регулярно — и про дисциплину, которая их ловит. Конкретные кейсы из публичного репозитория, разбор причин, методология. Плюс честно: сколько это стоит, и где автоматизация всё ещё ломается.

Загадка базы данных

Вся наша база данных находилась в памяти, однако операции поиска по ней занимали 12 тысяч тактов. При миллионе показаний датчика IoT-устройства с 64 КБ кэша реализация красно-чёрного дерева оказалась слишком медленной для запросов в реальном времени.

«Давайте попробуем B-дерево», — предложил я.

«Разве они нужны не только для баз данных на дисках? — спросил лид, — У нас всё находится в памяти. Чем нам будет полезно B-дерево?»

Вопрос был вполне разумным. B-деревья были придуманы для доступа к диску; каждый узел в них — это блок диска. Однако паттерны промахов кэша выглядели подозрительно похожими на паттерны дискового ввода-вывода — всего в 100 раз, а не в 100000 раз быстрее.

В итоге мы реализовали B-дерево. Результаты удивили всех...

Сегодня математика считается крайне абстрактной наукой. На форумах наподобие Stack Exchange опытные математики насмехаются над новичками, просящими понятных объяснений эзотерических математических концепций, а постоянные попытки привязать основы математики к реальности стали визитной карточкой онлайн-сумасшедших.

Мне кажется это ироничным: тысячелетиями математика оставалась более-менее естественной наукой. У нас не было философского объяснения тому, почему 2 + 2 должно быть равно 4. Мы просто наблюдали происходящее вокруг нас и пытались вывести правила. Абстракции были важны, но они обязательно должны были обосновываться объективной реальностью. Согласованности аксиом было недостаточно: углы нашего гипотетического треугольника должны были соответствовать углам в реальном мире.

Вы открываете горячую функцию в профилировщике, видите миллионы вызовов, добавляете #[inline(always)]. Бинарник распухает, время сборки подскакивает, а производительность не меняется. Или ваще падает. Проблема не в атрибуте. Проблема в том, что #[inline] делает совсем не то, что подсказывает интуиция.

На почти каждой Linux-машине в мире живёт один маленький бинарник. Весит несколько мегабайт, несколько десятков тысяч строк кода, поставляется со своим собственным конфигурационным языком, и CVE-шек за ним накопилось столько, что хватит на хорошую таблицу с фильтрами. Большинство из нас запускает его по десятку раз в день, не задумываясь.

Этот бинарник — sudo.

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

Вот о чём эта статья: что это за работа, как она обросла такой сложностью, и как маленькая программа на C справляется с ней лучше.

Почти 800 тестов, 10 минут на прогон, каждый пуш — ожидание на CI. Знакомо? Рассказываю, как довёл время до 101 секунды: снижение таймаутов, параллелизм ScalaTest, shared Testcontainers и защита от регрессий. Scala, SBT, PostgreSQL, GraalVM — конкретные шаги и подводные камни.

Начав изучать тему терминалов в Linux, вы можете почувствовать, что по отдельности вроде бы всё понятно, но разница между понятиями и их суть всё равно ускользает. Консоль, терминал, TTY, виртуальная консоль, виртуальный терминал, эмулятор терминала, оболочка — это просто «вот то чёрное окошко, куда вводят команды Linux». На самом деле за этим окошком скрывается целая цепочка разных сущностей — от компонентов ядра до пользовательских программ. Цель данной статьи — объяснить подсистему TTY и избавить вас от этого неприятного ощущения.

Привет Хабр! Возможно вас, как и меня, первое знакомство с функциональными зависимостями в базах данных повергло в легкий ступор. Длинные определения, которые не давались даже после третьего прочтения, излишняя абстрактность, когда на простые и понятные примеры поскупились, и прочее прелести «научного» подхода к объяснению сложных тем.

Пора раз и навсегда разобраться во всем этом. Тем не менее, я постараюсь не упускать детали и, где это уместно, углубиться в тему с головой. Без претензии на академичность, но с претензией на ясность. Начнем.

Привет, Хабр! Я Павел Михайлик, архитектор в центре сетевых решений «Инфосистемы Джет». Сегодня я расскажу о балансировке в сети и почему она важна при наблюдении за манулами. 

«Балансирование нагрузки», «ADC», «GSLB», anycast, ECMP, — много разных терминов и ещё больше разных сценариев реализации, как в постановке задачи, так и в методах и механике реализации. Итак, давайте попробуем для начала наметить основные критерии, по которым можно разделить разные типы балансирования нагрузки.

Для пользователя может показаться, что переход с HTTP/2 на HTTP/3 — это просто замена TCP на UDP в конфиге. Но для серверного ПО с многопроцессной архитектурой этот шаг превращается в настоящую «головную боль». Классическая схема с accept(), на которой годами строилась работа с TCP‑соединениями, в мире QUIC попросту не существует. Пакеты летят в UDP‑порт, и ядро ОС больше не знает, какому именно рабочему процессу их отдать.

В оригинальном nginx это привело к тому, что поддержка HTTP/3 уже долгое время остается «экспериментальной» и ограниченной: она страдает от проблем с обрывами сессий и деградации сервиса при обновлении конфигурации. Для многих это стало стоп‑фактором для внедрения протокола в реальный продакшен.

В этой статье мы расскажем, как в Angie 1.11 нам удалось устранить эти фундаментальные недостатки. Мы не просто добавили поддержку протокола, а пересмотрели механику взаимодействия с ядром. Путь от простых хешей до создания полноценного аналога accept() для QUIC с помощью BPF‑программ позволил нам заявить: реализация HTTP/3 в Angie закончена, лишена «детских болезней» nginx и полностью готова к эксплуатации в высоконагруженных средах.

Добро пожаловать под капот современного транспорта данных.

ЦОДы для ИИ уже несколько лет упираются в ограничения межсоединений. Ускорители становятся мощнее, кластеры разрастаются до сотен тысяч чипов, а передача данных между ними все чаще начинает тормозить масштабирование. Медь и оптика все еще работают, но по мере роста ИИ-кластеров становится ясно, что масштабировать такие решения все сложнее и дороже.

На этом фоне активные радиокабели (ARC) выглядят как более практичный вариант. Компании Point2 Technology и AttoTude предлагают передавать данные радиоволнами через пластиковые волноводы, а в отрасли все чаще говорят о copper cliff — моменте, когда медь перестает справляться с терабитными скоростями в плотных ИИ-стойках. Давайте разберемся, какие проблемы с межсоединениями накопились к 2026 году и почему радиочастотные решения на пластиковых волноводах начали привлекать внимание отрасли. 

Настоящая устойчивость систем — в архитектуре. В новом переводе от команды Spring АйО — 8 фундаментальных паттернов проектирования, на которых держатся все современные data engineering-стеки. Освоив их, вы перестанете тушить пожары и начнёте проектировать платформы, которые выдерживают продакшен.