В прошлой статье я обещал, что залезу под капот систем антиплагиата и расскажу, как они работают. Этим сегодня и займёмся.

В предисловии разочарованно скажу одну вещь. Инновации сделали из многих старых систем для вузов дорогостоящий генератор красивых, но бесполезных отчётов. Для этого хватило простого GPT-4o и его аналогов. Старые системы просто не видят нейросетевой текст, не распознают его.

Для этой статьи я проанализировал архитектуру нескольких ключевых систем и поговорил с разработчиком-архитектором, который строил их изнутри.

Вы знали, что ниша антиплагиата пухнет от денег? Я тоже не знал, пока не полез в тендеры и мировую статистику. К 2030 году мировой объем долетит до $5.9 млрд. Но на рынке творится какой-то абсурд.

Рынок российского антиплагиата — 1,5 милларда рублей. Официальной статистики вы не найдёте. Эту информацию я нашёл сам в тендерах и базе СПАРК. И эти деньги тратят на проверку «технической» уникальности.

В 2020 году можно было парсить шинглы, с чистой совестью продавать это ВУЗам и знать, что почти наверняка программа поймает всех плагиатчиков. Сейчас картина немного другая...

Технология eBPF — интересная штука. С её помощью можно без труда внедрять в ядро Linux фрагменты кода, которые затем компилируются в коды операций (опкоды), которые гарантированно не обрушат работу ядра. Набор допустимых инструкций ограничен, переходы назад не допускаются (поэтому не будет никаких неопределённых циклов). При этом вы не можете разыменовывать указатели, но вместо этого можете выполнять проверяемые операции считывания через указатели, которые потенциально могут оказаться неудачными, но при этом не спровоцируют паник на всю систему. eBPF в ядре Linux можно закреплять в тысячах хуков (точек перехвата), в качестве которых могут выступать u-пробы, k-пробы, точки трассировки и даже такие штуки как отказы страниц. У eBPF есть целый спектр захватывающих возможностей, которые при этом очень активно разрабатываются. Фичи, поддерживаемые в каждой конкретной версии ядра, перечислены в виде списка по этому адресу.

Аналитики CNewsMarket наблюдающие за рынком CRM с 2020 года, опубликовали свежие данные, и динамика последних лет впечатляет. Если раньше в топах мелькали знакомые западные логотипы, то рейтинг 2026 года фиксирует новую реальность: иностранные вендоры полностью уступили место отечественным разработчикам. Это не просто ​​«импортозамещение на бумаге​​», а свидетельство того, что российский бизнес достиг реальной технологической независимости в классе систем управления клиентами.

Многие ключевые игроки, попавшие в рейтинг CRM систем, развивают свою экспертизу уже более 10 лет, имея в портфолио масштабные Enterprise-кейсы, реализованные задолго до 2022 года. Импульс последних лет привел к появлению новых сильных команд и ускорил эволюцию продуктов. Рынок растет и вширь — насыщаясь ИИ-инструментами, омниканальностью и экосистемностью, и вглубь — создавая специализированные отраслевые решения.

Сегодня выбор CRM — это уже не компромисс между ​​«функционально​​» и ​​«безопасно​​». Это поиск стратегического партнера, способного поддержать рост бизнеса в условиях цифровой экономики. В этом материале мы опираемся на свежее исследование CNewsMarket. Мы детально разберем их данные, проанализируем лидеров списка и поможем понять, какая из лучших российских CRM систем 2026 года подойдет именно вашему бизнесу

Тезис: следует создать такой дистрибутив Linux, который по умолчанию выполняет двоичные файлы Windows через Wine.

Если я найду файл в формате .exe, которому 20 лет, я по-прежнему смогу запустить его на современной Windows. Попробуйте проделать подобное с двоичным файлом Linux, которому всего год. Совершенно не гарантированно, что он запустится, в зависимости от того, какие обновления успели произойти. Также не гарантируется, что заработает даже сегодняшний двоичный файл Linux, если собрать его в одном дистрибутиве, а попытаться запустить на разных других дистрибутивах. Возникает ровно такая же проблема, связанная с версиями установленных библиотек.

Большая часть работы по теории языков программирования и проектированию языков программирования касается аспектов (1) и (2), так как именно они наиболее важны, но лично я глубоко увлекаюсь фичами типа (3). Поскольку эти фичи такие мелкие, именно они наиболее активно перетекают из языка в язык, ведь добавить их можно совсем «малой кровью». Сам я много времени провёл за изучением нишевых малопонятных языков, и за этим встречал множество крутых фич из третьей категории — таких, с которыми вы, возможно, никогда не сталкивались. Расскажу о некоторых из них!

Когда вы вводите в командную строку docker run nginx — кажется, что произошло какое-то волшебство: за считанные секунды появляется полностью изолированная среда. Но здесь нет никакой магии, а просто инженерия ядра Linux. Давайте подробнее разберём эту тему подробнее и изучим, что именно происходит внутри ядра, когда Docker создаёт контейнер.

Тема безопасного и эргономичного взаимодействия между Rust и C/C++ была популярна на конференции RustConf 2025, состоявшейся в Сиэтле, штат Вашингтон. Чендлер Каррут выступил с презентацией, в которой представил различные способы взаимодействия между Rust и Carbon — экспериментальным языком, который можно условно обозначить как «(C++)++». Он резюмировал, что, пусть возможности стыковки Rust с другими языками со временем расширяются, в обозримом будущем не стоит ожидать, что будет полноценно решена проблема его взаимодействия с C++. Поэтому как раз появляется ниша для Carbon, который может предложить иной подход для постепенного совершенствования существующих проектов на C++. Вот слайды к его презентации — для тех, кто хотел бы изучить код его примеров более подробно.

Фича под названием перезапускаемые последовательности была добавлена в версию ядра 4.18 в 2018 году. Она позволяет повысить производительность в определённых категориях многопоточных приложений. Притом, что кому-то перезапускаемые последовательности действительно пригодились, такой код считается достаточно специализированным — как правило, разработчики приложений этим инструментом не пользуются. Но со временем перезапускаемые последовательности выросли и, по-видимому, тренд к их росту сохраняется, так как эта фича привязана к новым возможностям, предоставляемым в ядре. Но по мере того, как перезапускаемые последовательности стало всё сложнее считать нишевой фичей, с ними стали возникать заметные проблемы. Если исправить одну из них, это может повлечь заметные изменения ABI, которые будут видимы в пользовательском пространстве.

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

Практикующий инженер постепенно убеждается на собственном опыте, что дихотомия быстрый/медленный путь — это зачастую просто привлекательный мираж. Снова и снова мы видим, что попытка внедрить быстрый/медленный путь в реальной системе не даёт результата. Именно в этой области практика вступает в острое противоречие с теорией.

Вам когда-нибудь хотелось создать собственный системный вызов? Может быть, вы получали такое домашнее задание, пытались сделать это из интереса или просто для того, чтобы узнать что-то новое о ядре. В любом случае, системные вызовы – крутая штука, чтобы подробнее разобраться в Linux.

7 августа ровно в 11:00 по московскому времени тысячи игроков вспомнили, что такое очередь входа на сервер. А за неделю до этого увидели трейлер с, наверное, самым подходящим саундтреком для игры с огромным количеством разрушаемости.

Да, разумеется, речь идет о Battlefield 6, самом ожидаемом шутере этого года от огромной команды разработчиков во главе с Винсом Зампелла.

Я ворвался в бету ровно в 11 утра в день раннего доступа, стоически отстоял 150 тысяч человек в очереди, и отогнать меня от консоли с игрой было практически невозможно. И мне, как хардкорному фанату Call of Duty, есть что сказать.

Может ли ядро Linux при всей своей гибкости обеспечивать гарантированное время отклика при работе с приложениями?

Ядро Linux является универсальным и приспособлено к работе как с крошечными встраиваемыми устройствами, так и с титаническими серверами… а также со всем спектром машин между этими крайностями! Но может ли такое поразительно адаптивное ядро обеспечить гарантированную скорость отклика для приложения, работающего на всех этих платформах? Если в вашем приложении допустимая задержка при отклике укладывается в 200 микросекунд — то уверенно отвечаем на этот вопрос «да»! (Кстати, для Linux такая планка совсем не высока, но, чтобы её держать, потребуется тщательно подбирать аппаратное обеспечение и, возможно, обратиться за консультацией к специалисту по системам Linux, работающим в режиме реального времени).

Итак, почему же в приложении, работающем под Linux, иногда могут возникать задержки свыше 200 микросекунд? Универсальность ядра Linux требует сбалансировать пропускную способность, время отклика и честность распределения процессорной мощности, чтобы соответствовать требованиям такой универсальности. Если по одному из этих аспектов предъявляются жёсткие требования, то необходимо тонко настраивать как само ядро, так и поведение приложения. В этом посте рассмотрим 10 основных пунктов, которые необходимо учитывать при разработке системы Linux, к которой предъявляются строгие требования по работе в режиме реального времени. По каждому пункту также упомяну, в каком аспекте легко засыпаться разработчику-новичку, только приступающему к программированию систем реального времени под Linux.

Ссылки в Linux — это мощный инструмент, позволяющий указывать путь к файлам и каталогам. Существует два основных типа ссылок: жёсткие ссылки и мягкие ссылки (вторые также известны как символические ссылки или симлинки). Понимание различий между этими двумя типами поможет вам эффективно управлять файловой системой.

Поток — это последовательность элементов данных, предоставляемых за некоторое время. Концепция потока (stream) позволяет обрабатывать или передавать данные поэлементно, а не как одно целое. Потоки особенно полезны в сценариях, когда приходится работать с большими множествами данных, непрерывными данными или данными реального времени.

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

Ситуация на рынке ИТ-решений за последние годы изменилась — многие зарубежные вендоры ушли с российского рынка, что открыло новые возможности для отечественных разработчиков. Сегодня российские вендоры Service Desk утверждают, что не просто заменяют иностранные аналоги, но и предлагают уникальные преимущества: соответствие российскому законодательству, учёт местной специфики бизнес-процессов и техническую независимость. 

В обзоре рассмотрим самые ключевые вопросы при выборе Service Desk, оценим ключевые критерии выбора, задел которым дали иностранные решения и кратко пройдемся по основным вариантам на российском рынке.

За годы работы я подробно изучил, как центральные процессоры (CPU) выполняют код и как они устроены внутри. Дело в том, что я участвовал в разработке ядра Linux и ScyllaDB, а этот код очень близок к металлу. Я даже немного баловался с Verilog, безрезультатно попытавшись собрать моё собственное ядро RISC-V.

Графические процессоры (GPU) в отличие от обычных в основном оставались для меня чёрным ящиком, несмотря на то, что поработать с ними всё-таки довелось. Помню, что экспериментировал с NVIDIA RIVA 128 или чем-то подобным, проверяя, как там работает DirectX. Тогда такие процессоры ещё не выделялись на фоне ускорителей 3D-графики. Я также пытался идти в ногу со временем и немного упражнялся в программировании элементарных шейдеров на современных GPU. Но я никогда глубоко не вдавался в работу с GPU, и мои взгляды можно назвать CPU-центричными.

Однако, поскольку сегодня наблюдается всплеск рабочих нагрузок, связанных с ИИ, и, в частности, приходится работать с большими языковыми моделями (БЯМ), графические процессоры становятся незаменимыми для современных вычислений. К задачам, решаемым с применением ИИ, относятся масштабные прикладные тензорные операции, в том числе — сложение и перемножение матриц. А это уже работа для GPU. Но как современный GPU выполняет их, и насколько при этом возрастает эффективность по сравнению с выполнением таких же рабочих нагрузок на CPU?

В этой статье мы разберём, как написать программу для решения судоку. Предполагается, что ранее читатель не пробовал алгоритмически решать судоку, тем более — с применением нейронных сетей.

Однажды на работе техлид порекомендовал мне проштудировать книгу Understanding the Linux Kernel Бове и Чезати. В ней рассмотрена версия Linux 2.6, сильно не дотягивающая до более современной версии 6.0. Но в ней явно ещё много ценной информации. Книга толстая, поэтому на её изучение мне потребовалось немало времени. Занимаясь по ней, я решил настроить такую среду разработки, в которой я мог бы просматривать и изменять новейшую версию ядра Linux — чтобы было ещё интереснее.

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