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

2. Диктатура DRM и смерть института владения.

Главный юридический и технический обман современной цифровой дистрибуции кроется в аббревиатуре DRM (управление цифровыми правами). Покупая игру в Steam, EGS, Ubisoft Connect или EA App, пользователь не приобретает сам продукт. Согласно лицензионным соглашениям (EULA), которые никто не читает, вы покупаете лишь временную, отзываемую лицензию на запуск софта.

Вы полностью лишены права собственности: вы не можете перепродать игру, подарить её, обменять или оставить в наследство. Защитные системы (вроде Denuvo) и постоянное требование подключения к сети превращают купленный вами продукт в арендованный сервис. Издатель может в любую секунду отключить мастер-серверы, удалить игру из вашей библиотеки из-за истечения лицензий на музыку или заблокировать ваш аккаунт по щелчку пальцев модератора. Вы платите полную стоимость за физический воздух, который принадлежит корпорациям, но никак не вам.

3. Инфраструктурный тупик: лаунчер как надзиратель.

Современный ПК-гейминг превратился в абсурдный парад матрешек. Чтобы запустить игру от Ubisoft, купленную в Steam, вам нужно запустить клиент Steam, который внутри себя запустит Ubisoft Connect, который, в свою очередь, проверит лицензию через серверы Denuvo. Каждая из этих закрытых систем потребляет ресурсы процессора, собирает ваши телеметрические данные и создает дополнительные точки отказа.

Эта инфраструктура построена на тотальном недоверии к клиенту. Корпорации превратили лаунчеры из удобных библиотек в цифровых надзирателей. Вместо оптимизации софта и развития сетевых стандартов, ресурсы индустрии уходят на возведение цифровых заборов. Мы оказались в тупике, где удобство пользователя принесено в жертву паранойе правообладателей, а сама возможность запустить купленную игру напрямую зависит от стабильности серверов трех разных американских или европейских корпораций.

Direct Rendering Manager (DRM)

Развитие современных видеокарт пошло по весьма.. сюрреалистичному пути:

производители страстно желают, чтобы выпускаемые устройства имели максимальную совместимость с модными открытыми ОС, но одновременно были закрытыми и неповторимыми, защищенными разнообразными патентами.

То что звучит как чистая шизофрения для человека с техническим образованием, будучи спущенным сверху в виде директивы, еще и подкрепленной серьезным бюджетом, породило на свет такую «хтонь» как binary blob.

Затем вокруг создается открытая часть ПО, которая линкуется с открытым ядром и/или окружением. А все это вместе и без смущения объявляется как частично беременна открытое решение.

Еще в современном Linux есть такая штука как Direct Rendering Manager:

The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards

Если кратко и цензурно, то это такая специальная дыра в ядре Linux, для максимально быстрой коммуникации между видеокартой и клиентским ПО, создаваемая в первую очередь ради видеоиг.. скажем так «медийных приложений, требующих аппаратного ускорения графики».

В угаре оптимизации «ядростроители» дошли до использования 3D-ускорения (GPU) даже для отрисовки терминала текстовой консоли (тот самый KMS):

И теперь мы все имеем клевый терминал в разрешении 1920×1280 со сглаживанием шрифтов, на котором что-то разобрать возможно лишь с лупой прищурившись.

Угар портирования

Под натиском волн малолетних специалистов, желающих «гонять игоры» на серверной ОС, не выдержали даже разработчики FreeBSD:

подсистема DRM и KMS, вместе с проприетарными блобами была перенесена из Linux и теперь вовсю используется в FreeBSD.

По-умолчанию, да.

Кстати с тех лет и до сих пор разработка DRM синхронизируется с апстримом (а это внезапно отдельный проект) и ядром Linux, заезжая в сборки FreeBSD вместе со всеми свежими багами в виде срезов исходников. Основная разработка при этом едет дальше.

Нетрудно догадаться, что отправлять багрепорты в проект drm-kmod, курируемый FreeBSD или апстрим ядра Linux при таком подходе равнозначно отправке в «Спортлото».

Заодно во FreeBSD были фактически похоронены альтернативные варианты:

старый текстовый TTY и Xorg-драйвер для видеокарт Intel пока еще существуют и собираются в виде пакетов, но вот их настройку и главное — все сопутствующие сбои в клиентском ПО вы теперь вынуждены отлавливать и исправлять самостоятельно.

«Интерес сообщества» к таким технологиям оказался утрачен.

В качестве вишенки на этом интересном торте из говна, добавлю что всенародно любимый браузер Google Chrome плохо работает без модуля KMS, поэтому заводить весь этот цирк с DRM и KMS приходится даже на откровенно винтажных машинах — ради работающего браузера.

И других вариантов уже фактически нет.

Оборзевшая техника

Вся эта технологическая «многоножка» из разработчиков Intel с блобами, апстрима ядра Linux с любовью к тотальным переделкам на Rust, на практике приводит к тому, что в бедную FreeBSD постоянно попадают ломающие обновления, отследить и исправить которые «в моменте» не получается.

«Думали что работает» — говорят в таких случаях разработчики FreeBSD и советуют обновиться до -CURRENT версии.

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

В какой-то момент обновление пакета drm-kmod, содержащего тот самый порт подсистемы DRM из ядра Linux принесло мне такое:

drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080

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

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

При этом ошибка сама по себе довольно известная, страдают как пользователи FreeBSD:

Так и линуксоиды:

Но самое веселое, что баг оказался с рогами и копытами совсем не специфичным и само сообщение означает буквально.. ничего.

Просто «что-то сломалось», в переводе с языка Intel.

Ну что, вы все еще любите проприетарные драйвера от уважаемых производителей?

Беглый поиск в репозитории, в котором ведется разработка подсистемы DRM (напоминаю, она ведется отдельно от ядра Linux) показал, что сообщений с этой ошибкой навалом:

Положение дел

В итоге есть некий баг, с гнездом в районе прошивки видекарты Intel, который (судя по репортам) зверствует проявляет себя самым феерическим образом:

от спама сообщениями до мигания экрана и полного зависания системы.

Исправить своими силами этот баг нельзя, все «workaround» в сети по накалу дичи в рекомендациях напоминают известное шоу «Битва Экстрасенсов»:

нарисуйте ночью в поле пентаграмму из соли, разложите по углам загрузочные диски FreeBSD с 5й по 10ю и громко читайте Changelog задом наперед.

В качестве примера, вот так выглядит одно из решений:

Но есть и хорошие новости.

Хорошие новости

Их целых две.

Первая заключается в том, что в свежих прошивках баг вроде бы исправили на стороне Intel, но чтобы эту прошивку поставить — нужна сборка модуля DRM для FreeBSD 15, которая еще не была выпущена на момент написания статьи:

Еще стоит рассказать, что прямо сейчас идет серьезная работа по перепиливанию DRM как в его основном проекте так и на стороне команды FreeBSD (в -CURRENT), поэтому даже пытаться бекпортировать текущую версию drm-kmod в 14.х ветку не стоит.

Также (к сожалению) не стоит рассматривать переезд на 15ю версию как гарантированное решение, поскольку есть уже открытые багрепорты и оттуда:

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

compat.linuxkpi.i915_disable_power_well="0"

Так что конкретно в моем случае, проблема заключается лишь в бесконечном затирании буфера сообщений ядра этой дурацкой и бессмысленной ошибкой:

drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080

Которую мы и будем сейчас цинично глушить.

Аморальный патч

Разумеется так делать нельзя:

глушить сообщения об ошибках в ваших реальных проектах не стоит.

Хотя если в вашем проекте возникает ситуация, когда сообщение об ошибке генерируется по сотне раз за секунду — ну наверное вопрос уже к вам как к разработчику, допустившему такую дичь.

К счастью FreeBSD проект не мой, прямого доступа к разработчикам нет, а сам процесс разработки подсистемы DRM сильно напоминает известный фильм «Human Centipede».

Где (а главное — зачем) искать концы в такой ситуации не очень понятно, для примера багрепорты по ошибкам DRM в трекере ядра Linux сразу просят перенаправлять в отдельный проект, не разбираясь:

Так что было решено применить военную хитрость просто заглушить сообщение об ошибке в исходниках, пересобрав DRM из портов.

Так выглядит конечный результат после патча:

Поскольку новая 15я по счету версия FreeBSD еще официально не вышла на момент написания статьи, я все еще использую 14.3, где максимально доступная версия DRM для этой ветки — 6.1.

Ее мы и будем жестоко патчить.

В портах она находится в этом каталоге:

/usr/ports/graphics/drm-61-kmod

Поиск в исходном коде по тексту сообщения об ошибке показал, что генерируется она всего в одном месте, в файле i915_irq.c:

drivers/gpu/drm/i915/i915_irq.c

Так выглядит место появления:

..
fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv);

if (fault_errors)
drm_err(&dev_priv->drm,
"Fault errors on pipe %c: 0x%08x\n",
pipe_name(pipe),
fault_errors);
..

Все что нужно сделать — закомментировать этот блок, начиная с условия.

И все, больше вы это проклятое сообщение не увидите, ура.

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

Надо создать файл patch-i915_irq.c в каталоге /usr/ports/graphics/drm-61-kmod/files, затем вставить туда вот такое содержимое:

*** drivers/gpu/drm/i915/i915_irq.c.orig Tue Nov 18 17:17:39 2025
--- drivers/gpu/drm/i915/i915_irq.c Tue Nov 18 17:17:52 2025
***************
*** 2571,2585 ****

if (iir & gen8_de_pipe_underrun_mask(dev_priv))
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);

fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv);
! if (fault_errors)
drm_err(&dev_priv->drm,
"Fault errors on pipe %c: 0x%08x\n",
pipe_name(pipe),
! fault_errors);
}

if (HAS_PCH_SPLIT(dev_priv) && !HAS_PCH_NOP(dev_priv) &&
master_ctl & GEN8_DE_PCH_IRQ) {
/*
--- 2571,2585 ----

if (iir & gen8_de_pipe_underrun_mask(dev_priv))
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);

fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv);
! /*if (fault_errors)
drm_err(&dev_priv->drm,
"Fault errors on pipe %c: 0x%08x\n",
pipe_name(pipe),
! fault_errors);*/
}

if (HAS_PCH_SPLIT(dev_priv) && !HAS_PCH_NOP(dev_priv) &&
master_ctl & GEN8_DE_PCH_IRQ) {
/*

Дальше просто перезапускаем сборку:

make clean
make

Проверяем что изменения в файле i915_irq.cприменились и запускаем установку собранного пакета:

make reinstall

После чего перезагружаем систему.

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

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

P.S.

Ошибка действительно дурацкая, еще и наведенная — если дойдет до серьезных сбоев вроде мигания экрана (screen flickering), вы увидите дополнительные сообщения в логах, по которым можно продолжать искать реальную проблему.

Так что вопрос удаления этого сообщения чисто косметический и частично — лишней нагрузки, поскольку генерация сотен таких сообщений в секунду разумеется нагружала систему.

Статья была опубликована на Хабре, оригинал как обычно в нашем блоге.

Разработчики из студии The Astronauts в своем Discord-канале рассказали о том, почему решили не защищать RPG-шутер Witchfire какими-либо средствами защиты от пиратства. По словам разработчиков, компания придерживается такого подхода: если человек хочет спиратить игру, то он в любом случае сделает это каким-либо образом:

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

Кроме того, творческий директор студии, Адриан Хмеляж рассказал интересную историю одного студента из Египта, который недавно написал ему письмо.

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

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

При этом дела у The Astronauts идут отлично и без какой-либо антипиратской защиты: по словам разработчиков, игру уже добавили в список желаемого свыше 1,1 миллиона игроков в Steam и EGS. У игры очень положительные оценки в раннем доступе - 91% рейтинга. Witchfire вышла в раннем доступе в Steam 23 сентября.

Представлена карта времени выпуска для разных стран. В блоге Steam они ответили на некоторые вопросы и в частности заявили об отсутствие DRM защиты(УРА) в игре.

Ещё из интересного: Кроссплей между всеми платформами в первый день; Steam Deck планируется, но пока не реализован; Анти чит система - Easy Anti Cheat.