Формат и аудитория

Мы создаем «серьезно-развлекательные» статьи для взрослых, заинтересованных в ИТ-тематике — то самое «порно для инженеров»:

Стилистически это близко к первым выпускам знаменитого (ныне скатившегося) журнала «Хакер» и работам «известного гуманиста» Дани Шеповалова, если бы тот не забросил программирование сразу после ВУЗа и провел следующие 20 лет за серьезной разработкой ПО вместо бесконечных тусовок и ядерно-алкогольных трипов.

Таким образом контент, который мы выдаем это современная вариация концепции «комикса про супергероев», в данном случае — супергероев от ИТ и программирования. Создаваемый с такой же несбыточной мечтой о равенстве и справедливости:

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

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

Последняя надежда человечества под возрастающим гнетом машин.

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

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

Хотя-бы в теории и в масштабах статьи.

Мы не пытаемся косить под подростков и говорить с молодежью «на ты», не пытаемся выдерживать алкогольно-хулиганский стиль почившего ныне Udaff.com и уж точно не пишем корпоративным канцеляритом — как в ТЗ по 44ФЗ на разработку ПО.

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

Но разумеется накал выдаваемой дичи регулируемый и у вас будет возможность «пощелкать тумблерами».

Рамки и ограничения

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

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

Так чтоб #бнуло.

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

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

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

Авторские права

Мы можем передать как все права на создаваемый контент, так и ограничиться правами на публикацию. Во втором случае будет необходимо сохранить ссылку на автора при публикации на любых ресурсах, зато в первом можно договориться о чем угодно, вплоть до «white label» — полном обезличивании материала.

Разумеется первый вариант будет существенно дороже.

Paywall и платный доступ

Наш контент создается в первую очередь для развлечения широкой аудитории и не преследует каких-то серьезных образовательных целей.

Так что практический смысл сокрытия его под paywall ради платного доступа — под большим вопросом.

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

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

Варианты статей

На данный момент существует два основных варианта заказной статьи:

• классическое «инженерное порно», создаваемое и публикуемое со спонсорской поддержкой;
• полностью рекламная статья, создаваемая в нашем незабываемом стиле для продвижения вашей компании или сервиса.

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

Вариант 1. Золотая классика

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

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

Классический пример такой статьи из недавних: Интересные развлечения со змеей.

Вариант 2. Чисто рекламная история

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

Что не работает

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

Да, пробовали, нет не работает.

Что работает

Классическая серьезная наука, промышленность, история ИТ, официальные учебные заведения — с радостью расскажем читателям о, например, реальных научных разработках, обучении студентов программированию в реальном ВУЗе, не на онлайн-курсах.

Отлично зайдет история с хостингом, с серверами и сетевым оборудованием, с интернет-магазином электроники, с какими-то собственными разработками в сфере электроники и ПО.

К сожалению в 21 веке уже не прокатит простая рекламная статья, не прокатит и сложная — с нативной интеграцией, «темными паттернами» и прочей психологической магией.

Поэтому мы делаем аккуратно, но «в лоб»:

• не скрываем, что статья коммерческая и создана для продвижения конкретной компании, сервиса или услуги;
• обязательно даем конкретику — в статье будет конкретный кейс использования сервиса, возможно какая-то история, но четкая и конкретная.

Хороший пример из недавних:

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

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

Процесс

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

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

1. Мы создаем под вас уникальную историю на основе продвигаемого сервиса, товара или услуги, так чтобы не оттолкнуть читателей вульгарной «джинсой», но при этом раскрыть возможности продукта.

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

3. Собираем материал: фактуру, скриншоты, настройки и т.д.

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

5. Передаем вам финальную версию в формате Markdown, опционально помогаем с публикацией в соцсетях.

6. Переходим к пункту 1. (шутка)

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

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

Договор и оплата

Работа по созданию статей осуществляется согласно договору, чаще всего это будет договор ГПХ.

У нас есть готовые шаблоны договоров и большой опыт их применения, поэтому сможем ответить на все вопросы по НДС, НДФЛ и закрывающим документам — все покажем, расскажем споем и спляшем.

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

Конкретная стоимость статьи будет озвучена в день обращения и будет зависеть от текущих реалий:

курса доллара, % инфляции, продвижения наших войск, твиттера Трампа и всех прочих событий в мире, влияющих на наши расходы и светлое будущее.

По-другому увы, никак.

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

Нет оплаты — нет работы (ц) Сократ.

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

А у нас от этого несварение кассовые разрывы.

Публикация в соцсетях

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

Можно комбинировать оба варианта, можно публиковать у вас в корпоративном блоге, затем давать анонс со ссылками на наших площадках — вариантов масса и все интересные.

Наши каналы

Полный список наших каналов:

Основной ресурс для публикации наших статей, отсюда они расползаются по интернету.

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

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

Дублируем тут наши статьи ввиду переодических блокировок платформы Teletype, на которой работает блог.

Дублируем наши статьи на этой площадке, ввиду большой аудитории. Ныне это вторая после Хабра площадка для публикаций.

Публикуем только анонсы новых материалов. По согласованию с вами, поскольку ресурс под санкциями.

Только анонсы новых материалов.

Только анонсы новых материалов.

Только анонсы новых материалов.

Публикуем только анонсы новых материалов. По согласованию с вами, поскольку ресурс под санкциями.

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

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

Бекстейдж

В случае стандартного пути, во время работы над статьей мы делаем несколько постов в нашем Telegram-канале с бекстейджем — демонстрацией процесса работы над статьей, в качестве промо-материалов для нагнетания интереса к будущему шедевру:

Публикация

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

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

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

После публикации мы делаем анонс статьи в нашем канале, с указанием всех ссылок:

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

При публикации коммерческой статьи в наших соцсетях (по согласованию), обязательно вставляется плашка спонсора, со ссылками:

Продвижение ИИ

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

Повсеместное внедрение ИИ идет с очевидными перегибами:

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

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

С чего простой народ звереет и «всех этих ИИ и роботов» откровенно ненавидит:

Переломить эту ситуацию с позиции автора не получится ни за какие выделяемые бюджеты:

не будет простой курьер, студент или работник охраны — коих большинство среди наших читателей, лениво листающий Двач Хабр после смены, восторгаться и лайкать ИИ, который «отбирает его работу».

Да, мы пробовали.

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

Повторюсь:

Просто есть определенные реалии и сложившаяся аудитория, которая не принимает такой контент, даже написанный в нашем незабываемом стиле.

ИИ и контент

Несмотря на острое желание, наличие опыта и даже талантов — мы не используем ИИ при написании текстов. По одной простой, но очень веской причине:

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

Повторюсь:

малейший признак, речевой оборот или характерная для ИИ фраза в тексте и все летит в печь, а статья (вместе с автором) собирает негатив.

Единственный тип ИИ-контента, который отлично работает для массовой аудитории это смешные картиночки:

Такой искусственный контент интересен своей абсурдностью и невозможностью показанной ситуации, вроде сцены из Форреста Гампа выше, где вместо главного героя на лавочке сидит Тони Сопрано с диснеевской принцессой.

Примерно на такой же идеи абсурда, возведенного в абсолют выезжает известный мультсериал «South Park».

Эти самые «боевые картиночки» мы ставим в качестве обоев, когда делаем иллюстрации к нашим статьям:

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

Оставшиеся 10% приходятся (чаще всего) на фото известных персонажей или исторические хроники.

Цифры, отзывы и охваты

Самое важное, ключевое и главное:

Что выражается в невероятно малом количестве негатива и выражаемой ненависти под публикуемым контентом, только взгляните:

Или другой пример:

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

Хотя Хабр — не единственный пример площадки, где широкая аудитория по достоинству оценила наши работы, взгляните:

Почти 300 лайков на сугубо развлекательном портале «Пикабу» за серьезную статью про суперкомпьютеры Cray, где типичный контент это обычно про пердеж и котиков..

Помимо народной любви, наш контент отличает стабильность охватов:

практически каждая публикуемая статья набирает 10к и выше уникальных просмотров, как на Хабре так и на Пикабу.

Отдельные шедевры улетают сильно дальше:

Практически под каждой статьей есть комментарии и активная дискуссия.

Нас цитируют:

На нас ссылаются:

И конечно практически все наши статьи, публикуемые на Хабре активно копируют на свои ресурсы различные фанаты, что суммарно дает аудиторию, сопоставимую со всей ИТ-индустрией в РФ.

Вливайтесь.

Контакты автора не изменились:

ТГ/VK/Хабр/Пикабу/Дзен/LinkedIn/Youtube:  alex0x08 
Почта: alex3.145@gmail.com
MAX: +7 903 182 65 71

В моем, весьма специфическом случае такой нереализованной мечтой детства долгое время оставался.. компилятор Watcom, дорваться до которого удалось лишь спустя почти тридцать лет.

Рассказываю об этом удивительном проекте.

Детская травма

Хотя я уже неоднократно и красочно описывал разные интересные компиляторы далекого (и не очень) прошлого, история с Watcom C/C++ отличается:

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

Но поскольку жил тогда сильно далеко от столиц — найти такое чудо на местных BBS развалах CD-дисков было проблематично.

А когда заветные диски все же удалось раздобыть, возникла куда большая проблема — как в этом всем разобраться, в 16-то лет:

Увы, но чуда тогда не случилось, Цукерберг так и не позвонил и моя карьера программиста ушла в сторону Java и серверов приложений, вместо нативной разработки на C++. Ну, а продукт от Watcom постепенно терял свои лидерские позиции среди инструментов разработки и уже к началу 2000х полностью пропал из актуальной повестки.

Наверное теперь вы задаетесь вопросом:

откуда подросток из глухих сибирских краев вообще мог узнать о столь специфичной вещи, чтобы потом ее целенаправленно искать?

Все довольно просто и даже очевидно:

Да да, те самые «компьютерные игоры», увлечение которыми в моем случае пошло сильно не туда — вместо того чтобы в них играть и деградировать, я начал их препари.. разбирать на части, в попытках понять как же оно устроено.

Знаменитый DOS/4GW фигурировал в описании системных требований почти каждой компьютерной игры тех лет, а слово «Watcom» быстро нашлось при визуальном осмотре EXE-файла, из которого запускалась одна из самых любимых игр:

Так я узнал, что на свете существуют компиляторы Watcom.

Легендарная мощь

Теперь серьезно.

Набор оптимизирующих компиляторов и средств разработки Watcom C/C++ долгое время оставался одним из лучших инструментов для профессиональных программистов, в первую очередь из-за своей производительности:

In a February 1989 overview of optimizing C compilers, BYTE praised Watcom C 6.5's "unmatched execution speed" and noted that it was the most ANSI C-compliant.

Еще одной причиной народной любви к этому тулчейну была его портабельность  — Watcom C/C++ поддерживал много разных платформ, причем как на хосте, так и в качестве целевых:

Собственно списком выше закрывались практически все потребности Windows-программистов тех лет, поскольку Watcom C/C++ поддерживал все актуальные на тот момент платформы и архитектуры.

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

Печальная история

К сожалению Watcom пришлось повторить судьбу многих других легендарных проектов:

In 2000, Sybase, who owned Watcom International Corporation halted the commercial sale of the Watcom C/C++ and Fortran compilers.

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

Прекрасно понимаю что «бизнес есть бизнес», но по какой-то причине уникальные проекты, будучи поглощенными крупной компанией, неизменно проигрывают корпоративной бюрократии. После чего они скатываются, теряя свою уникальность, окончательно загибаясь в корпоративных застенках.

Так что печальная история Watcom C/C++ на самом деле весьма обыденна, но в данном случае это был еще не конец.

OpenWatcom

Цитируя википедию:

In 2003, SciTech Software Inc, a customer of Sybase, negotiated wth Sybase, to have the code for the compilers released as an open source project under a new name, OpenWatcom.[2]

Так на свет появился новый проект «Open Watcom» — открытый форк Watcom C/C++, разрабатываемый по открытой модели и с прицелом на сообщество энтузиастов.

К сожалению компания SciTech, организовавшая сей праздник щедрости несколько переоценила собственные возможности:

проект компилятора это «серьезно и надолго», требует участия огромного количества высоквалифицированных программистов.

Которые разумеется бесплатно не работают.

Видимо именно от такого надрыва компания и закончила свои корпоративные дни в 2008 году, будучи проданной канадской Alt Richmond Inc. Которая ныне также не существует.

На фоне всех этих печальных событий, к середине 2010 года работы над проектом «Open Watcom» были свернуты:

The last stable version endorsed by the original openwatcom.org team was 1.9, released in June 2010.[3][4]

OpenWatcom V2

Но интерес к проекту OpenWatcom все же сохранился, поэтому уже к 2015 году «упавшее знамя» разработки было подхвачено сообществом — теми самыми энтузиастами, ради которых проект когда-то открывали:

We are back!
Open Watcom is like a mythical bird Phoenix that never dies
and rises again from the ashes.
So do we.
The reports of our death are greatly exaggerated.

Так появился проект OpenWatcom V2 — открытый форк открытой версии компилятора Watcom C/C++.

Несмотря на столь бодрые заявления новой команды и обнадеживающий поток свежих коммитов в репозитории, ныне проект находится скорее в «цифровом чистилище», зависнув между возрождением и окончательной смертью:

стабильных релизов как таковых нет с 2015 года и народ выкладывает «daily builds» — ежедневные сборки.

Поэтому как новая версия 2.0 так и устаревшая, но пока еще поддерживаемая 1.9 на самом деле собираются из разных master-веток и с текущим набором коммитов.

Вот такие привратности судьбы в стиле «Игры престолов» Дж. Мартина — падение от «very popular compiler for high-end games» до дважды закрытого проекта, форкнутого на потеху энтузиастам.

Славные гусарские традиции и FreeBSD

Как уже упоминал выше, Watcom и оба его продолжения — весьма портабельны, причем расширение списка поддерживаемых платформ является одним из постоянных направлений работ:

There is ongoing work to extend the targeting to Linux and modern BSD operating systems, running on x86, PowerPC, and other processors.

Все настолько поехали далеко зашло, что в скрипте сборки присутствует даже Haiku и DragonFly, хотя конечно есть определенные сомнения в стабильности работы на столь редких платформах .

Как бы то ни было, компиляторы Watcom воспринимались программистами как инструмент в первую очередь Windows-разработки.

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

Справка для обывателей

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

Во-первых существуют готовые сборки OpenWatcom: 2.0, 1.9, которые достаточно скачать и распаковать.

Каждая такая сборка содержит набор компиляторов для всех поддерживаемых платформ: MS-DOS, Windows, Linux и так далее, с разделением на 16, 32 и 64-битные версии, чем мы дальше будем активно пользоваться.

Но поддержки FreeBSD в готовых сборках разумеется нет.

Во-вторых, если вдруг Бог наказал вас использованием ArchLinux вместо операционной системы, в AUR есть готовые пакеты с OpenWatcom, как 2.0 так и 1.9 версий, которые достаточно «просто установить».

Ну и само собой разумеется, для «Windows-бояр» ничего устанавливать не придется само упадет, достаточно распаковать и прочитать инструкцию.

Новые приключения неуловимых

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

Впрочем и на более ранних версиях особых проблем замечено не было.

Начнем с малоизвестного для простых обывателей факта:

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

Который называется bootstrap compiler и используется на начальных этапах сборки таких проектов.

В качестве bootstrap-компилятора в моем случае использовался gcc13, который должен быть установлен в системе вместе со всем своим окружением.

Дополнительно, для отдельных стадий сборки, потребуется эмулятор Dosbox, также доступный в портах.

Ввиду особенности FreeBSD в виде приделывания номера версии к управляющим приложениям GCC, необходимо создать ссылку:

ln -s /usr/local/bin/g++13 /usr/local/bin/g++

Альтернативный вариант это ручная правка скриптов сборки, с массовой заменой вызываемого g++ на g++13, скрипты довольно большие и сложные, поэтому если захотите такое провернуть — правок будет много.

Но вернемся к нашей сборке.

Сборка OpenWatcom

Ультимативно и не мелочась, забираем исходники OpenWatcom сразу из master-ветки:

git clone --depth 1 https://github.com/open-watcom/open-watcom-v2.git

История коммитов весьма объемна, поэтому стоит указать ключ --depth 1.

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

cp setvars.sh local_setvars.sh

Затем изменить локальную копию — необходимо найти и раскомментировать параметр OWDOSBOX, указывающий на название исполняемого файла эмулятора Dosbox:

export OWDOSBOX=dosbox

Дальше необходимо этот скрипт запустить, чтобы в окружении появились все заданные там переменные (для bash):

source ./local_setvars.sh

При запуске отобразится используемый bootstrap-компилятор:

Теперь наконец запускаем саму сборку, не забывая молиться:

./build.sh

Сразу предупреждаю, процесс сборки будет идти долго даже на мощном компьютере, сравнимо по времени со сборкой ядра Linux, OpenOffice и других крупных проектов. На диске должно быть ~4Гб свободного места.

Объясняется это тем, что в процессе будут собираться компиляторы и инструментарий под все поддерживаемые ОС и архитектуры.

Если вам повезет и сборка завершится успешно, следующим шагом будет необходимо собрать релизную версию:

./build.sh rel

Который будет находиться в каталоге rel.

Дальше копируем готовую релизную сборку в то самое место, откуда собираемся потом использовать:

mkdir /opt/app/watcom
cp -r rel/* /opt/app/watcom/ 

Теперь создаем скрипт с переменными окружения, который будет необходимо подключать до начала использования OpenWatcom:

#!/bin/sh
export WATCOM=/opt/app/watcom 
export PATH=$WATCOM/binb64:$PATH 
export INCLUDE=$WATCOM/h:$WATCOM/h/nt 
export EDPATH=$WATCOM/eddats 
export WIPFC=$WATCOM/wipfc

Поскольку в переменную PATH добавляется каталог binb64, после применения скрипта будет использоваться нативная сборка OpenWatcom для FreeBSD, не для Linux или Windows:

Тем не менее, нативная сборка, как оказалось, вполне неплохо справляется с задачами кросс-компиляции под DOS и даже Windows, что мы будем использовать далее.

辻斬り

Цудзигири (辻斬り или 辻斬, дословно: убийство на перекрестке, англ. Tsujigiri) — японская практика, когда самурай, получив новую катану или разрабатывая новый вид боя или оружия, испытывал его эффективность, нападая на случайного оппонента.

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

Конечно можно было ограничиться примерами, которые идут в комплекте с OpenWatcom и на этом успокоиться, благо там весьма неплохая и функциональная подборка:

Но подумав, что это будет слишком уж скучно для читателей и недостойно упоминания в летописях, собрал с помощью OpenWatcom действительно интересный исторический проект — тот самый «Duke Nukem 3D», с которого когда-то началось мое с ним знакомство.

Duke Nukem 3D

Duke Nukem 3D это такая древняя (1997 год) стрелялка, где инопланетные монстры, «свинокопы» с дробовиками, стрельба из ракетниц с двух рук и прочие милые подростковые радости:

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

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

Поэтому позже я продолжил интересную практику картостроения уже в серии игр Quake.

Но про мой замечательный опыт игростроя расскажу как-нибудь отдельно, благо это весьма интересная история, а пока вернемся к истории с Watcom и сборкой «Duke Nukem 3D» из исходников.

Конечно же исходный код столь популярной и коммерчески успешной игры увидел свет далеко не сразу:

Целых семь лет фанаты донимали разработчиков, кивая в сторону ID Software, создавшую практику раскрытия исходников собственных игр. И наконец это случилось:

1 апреля 2003 года исходный код игры «Duke Nukem 3D» увидел свет.

Но поскольку на дворе были 2000е и к тому времени появилась бесплатная версия OpenWatcom, разработчики решили помочь энтузиастам, переделав оригинальную сборку, чтобы игру можно было собрать обоими версиями компиляторов:

Duke was originally written with the Watcom 10.0 C/C++ compiler. 
This code has been updated to allow it to compile under the free version 
of the Watcom compiler available from their webpage 
(http://www.openwatcom.org).

Таким образом официальная версия исходников Duke Nukem 3D, увидевшая свет в 2003м году поддерживала сборку с помощью OpenWatcom, но к сожалению его первой версии, которую затем форкнут энтузиасты.

Поскольку 1.x версия OpenWatcom (включая даже последнюю в линейке 1.9) имеет проблемы совместимости с 2.0, для того чтобы собрать из исходников «Duke Nukem 3D» именно второй версией придется мигрировать проект — переделывать скрипты сборки и (немного) исходники.

Хотя такая миграция и не представляет серьезной проблемы, делать ее вручную не придется, поскольку известный в узких кругах товарищ neozeed уже успел это сделать за нас, выложив в отдельном репозитории версию исходников с поддержкой OpenWatcom 2.0.

Забираем:

git clone https://github.com/neozeed/duke3d-openwatcom2.git

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

Ниже я покажу два варианта сборки:

• из-под DOS с помощью Dosbox и DOS-версии OpenWatcom;
• по боярски из-под Wine и с помощью Watcom IDE.

Оба варианта по своему экстремальны, поскольку дело будет происходить на FreeBSD, но самое интересное вас ожидает как обычно в конце повествования.

Чистый DOS

Как уже упоминал выше, при сборке OpenWatcom создаются версии компиляторов под все поддерживаемые платформы:

Собирается по-умолчанию далеко не все, поэтому список ниже не полный:

• binb64 — 64-битная сборка под FreeBSD
• binl — 32-битная сборка под Linux
• binl64 — 64-битная сборка под Linux, не собирается по-умолчанию
• binnt - 32-битная cборка для Windows
• binnt64 - 64-битная сборка для Windows
• binp — сборка для OS/2
• binw — 16-битная сборка для Windows и DOS

С учетом такого подхода, система сборки wmake в подкаталоге binw будет представлять собой приложение для DOS:

А в версии для Windows — в подкаталоге binnt это будет уже Win32-приложение:

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

Создаем новый каталог duke3d-work:

mkdir duke3d-work

Линкуем внутрь каталог с Watcom, чтобы не иметь проблем с длинными путями каталогов:

ln -s /opt/app/watcom ./watcom

Копируем исходники Duke Nukem 3D:

cp -R /opt/src/duke3d-openwatcom2/ ./duke3d

Теперь создаем в корне файл env.bat с таким содержимым:

@ECHO OFF
SET WATCOM=C:\WATCOM
SET PATH=%WATCOM%\BINW;%PATH%
SET EDPATH=%WATCOM%\EDDAT
SET INCLUDE=%WATCOM%\H
REM SET LIB=
REM SET WWINHELP=%WATCOM%\BINW

И стартуем Dosbox с указанием этого файла, обязательно из текущего каталога:

dosbox env.bat 

В результате запустится эмулятор DOS с подготовленным окружением для сборки:

Теперь переходим в каталог DUKE3D и запускаем сборку проекта:

CD DUKE3D
WMAKE

Надо отметить, что сборка происходит весьма неспешно — несмотря на небольшое количество файлов в проекте, исходного кода в каждом из них навалено с избытком:

К сожалению сборка немного сломана, поэтому через какое-то время процесс прервется с ошибкой:

Ошибки происходят из-за того что игра использует части движка Build (что логично), который необходимо собирать отдельно до самой игры.

Так что переходим в каталог с движком и запускаем отдельную сборку:

CD BUILD\SRC
WMAKE

Движок должен собраться без ошибок:

Теперь возвращаемся обратно в каталог с игрой и повторно запускаем сборку:

CD ..\..
WMAKE

Все требуемые файлы найдутся, кроме одного:

Как именно получилось, что один из ключевых файлов движка оказался пропущен в скрипте сборки от neozeed гадать не берусь, но для исправления ситуации необходимо добавить новый блок в build\src\makefile:

mmulti.obj : mmulti.c
	wcc386 mmulti /4r /s /or

Затем выполнить сборку отдельно для этого файла, чтобы получить искомый mmulti.obj:

CD BUILD\SRC
WMAKE MMULTI.OBJ

В результате должен собраться этот пропущенный файл:

Возвращаемся в каталог с игрой, удаляем game.obj, который окажется битым из-за пропущенного файла и заново запускаем сборку:

CD ..\..
DEL GAME.OBJ
WMAKE

На этот раз сборка должна завершиться успешно и даже сформируется заветный DUKE3D.EXE, но появится сообщение с ошибкой про отсутствующие инструменты для встраивания DOS4/GW:

Взять эти два файла можно например тут, их необходимо скопировать в каталог binw, где расположена DOS-версия OpenWatcom, после чего удалить недоделанный DUKE3D.EXE и перезапустить сборку:

DEL DUKE3D.EXE
WMAKE

Теперь наконец релизная сборка успешно завершится:

Файл D3D.EXE будет той самой релизной версией игры.

Но это все — скучные и непонятные «буковки на черном экране», все приличные программисты как известно используют такую штуку как «среда разработки» и у Watcom она очень даже есть.

Wine, Watcom и IDE

Среда разработки официально называется Watcom Integrated Development Environment и собирается из исходников при сборке компилятора, к сожалению только для Windows-платформ. Использование требует предварительно заданных переменных окружения, поэтому ее запуск из-под Wine — весьма нетривиальное занятие.

К счастью, автор успел съесть целую стаю собак на нетривиальных проектах и история с Watcom на этом шаге не обрывается.

В корневом каталоге проекта, рядом с env.bat, который мы создавали ранее для сборки с помощью Dosbox, создаем еще один файл env-nt.bat с таким содержимым:

@ECHO OFF
SET WATCOM=z:\opt\app\watcom
SET PATH=%WATCOM%\BINNT;%PATH%
SET EDPATH=%WATCOM%\EDDAT
SET INCLUDE=%WATCOM%\H;%WATCOM\H\NT%
REM SET LIB=
REM SET WWINHELP=%WATCOM%\BINNT

Из интересного тут путь в переменной WATCOM, который должен указывать на каталог с релизной сборкой OpenWatcom, но при этом иметь том Z: и разделитель в стиле Windows.

Том Z: это специальная уличная магия из Wine для бесшовного доступа к файловой системе хоста, с ее помощью можно указать путь к каталогу, который физически находится на диске FreeBSD, но должен использоваться из программы для Windows.

Запуск также представляет определенную проблему, поскольку с недавних пор Wine для FreeBSD поставляется только 64-битной версии и для эмуляции 32-битных приложений используется специальный цирк на конной тяге запуск.

Вводим:

wine wineconsole

Запустится новое приложение-терминал, аналог cmd.exe, работающий на базе Wine. Вводим уже в нем:

ent-nt.bat

Затем проверяем командой set, что переменная WATCOM указывает на нужный каталог:

Теперь наконец запускаем среду разработки:

ide.exe

Среда очень быстрая, хотя и весьма специфичная на нынешние времена, работает и сборка и отладка и запуск финального приложения, но разумеется в пределах возможностей Wine, поэтому запустить или отладить приложение для DOS, OS/2 или Win16 так просто не получится.

Вот так выглядит сборка и запуск Win32-версии знаменитой игры «Life», которую можно найти в примерах для OpenWatcom:

Теперь можно вернуться к проекту «Duke Nukem 3D» и собрать его наконец «по взрослому» — из среды разработки.

В меню File->Open Project выбираем файл duke3d.wpj и нажимаем кнопку Open:

Откроется проект со списком файлов с исходниками , по двойному клику на файле запустится редактор, в котором собственно и происходит работа с исходным кодом:

Собрать проект можно кнопкой «Make current target» на панели инструментов:

Сборка из среды довольно серьезно отличается от версии с wmake, поэтому при запуске появятся новые интересные ошибки:

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

• копируем файлы из каталога libs в корень проекта;
• копируем файлы mmulti.obj, cache1d.obj, engine.obj,a.obj из каталога build\src в корень проекта.

После этого сборка из IDE должна завершиться успешно:

Вот таким нехитрым способом (даже двумя) мы получили исполняемый файл знаменитой игры «Duke Nukem 3D», собранный из исходников с помощью компилятора Watcom — чего только не сделаешь из-за детских комплексов.

Самое время попробовать запустить.

Грандиозный провал

Ввиду прошлой известности и популярности, архивы с «Duke Nukem 3D» до сих пор можно легко найти в интернете. Ныне оригинальная игра является «abandonware» (заброшенным софтом), поэтому свободно доступна для скачивания с фанатских сайтов.

Скачиваем, например отсюда, распаковываем архив, заменяем DUKE3D.EXE на собственноручно собранную копию (D3D.EXE в случае сборки из-под DOS) и пробуем запустить с помощью Dosbox.

И получаем.. грандиозный провал:

Думаю на этом месте многие читатели вздохнули с облегчением и обрадовались:

«гусарский наскок» с шашкой на танк с нестабильными сборками из исходников под неподдерживаемой операционной системой закончился предсказуемо.

На пятнадцатой минуте статьи, после шагов по сборке компилятора, запуску и сборке самого Duke Nukem 3D из исходников, получился.. битый EXE-файл, попытка запуска которого вешает эмулятор.

И наверное на этом печальном абзаце статья бы и закончилась, будучи списанной в утиль за столь позорный провал. Если бы автор был нормальным обычным человеком.

И разразилась битва

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

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

Поэтому конечно автор не отступил и как уже можно было заметить по заглавной картинке к статье — все-таки повесил «отрубленную голову OpenWatcom» у себя над камином.

Теперь рассказываю как это было.

Первым делом я попробовал замедлить эмуляцию, задав более точную настройку CPU, соответствующую компьютерам тех лет в ~/.dosbox/dosbox-<версия>.conf:

..
[cpu]
core=normal
cputype=pentium
cycles=fixed 30000
..

Там же полностью отключил звук, затем переключил реализацию движка отрисовки на более совместимую.

К сожалению ничего из этого не помогло и собранная с таким трудом версия DUKE3D.EXE продолжала вешать эмулятор, тогда как оригинальная работала без каких-либо проблем.

Пробовал и запуск в полной эмуляции оригинального MS-DOS 6.22 с помощью 86Box, пробовал и другую реализацию расширителя памяти dos32a — с его помощью эмулятор перестал падать, но вместо картинки был лишь черный экран.

Следующим шагом был отказ от собранной под FreeBSD версии OpenWatcom и проверка на готовом билде для Linux:

Увы, но все это не помогло и собранная из исходников версия «Duke Nukem 3D» продолжала стабильно вылетать, выбешивая автора роняя эмулятор.

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

Забрав оригинал из этого репозитория на Github, я последовательно прошелся по всем правкам, созданным neozeed и добился таки сборки оригинальных исходников с помощью второй версии OpenWatcom.

Зато я заметил важную деталь:

Даже в оригинальной версии почему-то присутствовали готовые объектные файлы (.OBJ), несмотря на наличие рядом исходного кода.

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

Как оказалось в дальнейшем, веская причина действительно была.

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

Таким образом, поиск проблемного места сократился до четырех объектных файлов. Дальше все было совсем просто:

методом исключения, последовательно подменяя исторические OBJ-файлы на собранные вручную, был наконец определен виновник сбоев.

Все свелось к одному единственному файлу A.OBJ и его исходному коду A.ASM.

Ассемблер наносит ответный удар

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

Но тогда у читателей осталось бы ошибочное представление о поиске решения столь нетривиальной проблемы как о чем-то простом и обыденном.

В реальности это был весьма напряжненный процесс «кровавого ресерча», который закончился успехом практически случайно.

Но вернемся к нашему A.OBJ.

Оказалось, что сей интересный файл содержит ключевую часть игрового движка Build, на котором работает «Duke Nukem 3D», а его исходный код A.ASM представляет собой ~2000 строк на чистом ассемблере. Что весьма немало для чистого ассемблера, не каждый демосценер осилит столько наклепать.

Причем ассемблерный код написан так, что собрать его возможно только с помощью WASM из пакета OpenWatcom:

;Warning: IN THIS FILE, ALL SEGMENTS ARE REMOVED.  THIS MEANS THAT DS:[]
;MUST BE ADDED FOR ALL SELF-MODIFIES FOR MASM TO WORK.

Поскольку ничем другим (TASM/MASM/JWASM) собрать действительно не получилось, я решил обратиться к Марксу первоисточникам, прочитав наконец описание сборки:

the assembly is built with version 10, and the audio library is version 11

И все встало на свои места.

Позже были найдены и другие интересные проблемы, связанные со спецификой ассемблера от Watcom, затем подтвердились требуемые шаги по сборке Duke Nukem 3D строго определенной версией Watcom:

For Duke3D v1.5, use Watcom C 10.0 and *not* any other version; Not even 10.0a or 10.0b. For any of Matt's EXEs, use Watcom C 10.6a (and no other version)

Это чудо, что мой «кавалерийский наскок» с нестабильной версией OpenWatcom v2 и под FreeBSD вообще позволил хоть что-то собрать.

Был найден пост с готовым Watcom-окружением для сборки Duke Nukem (у все того же neozeed), в приложенном архиве находится все необходимое:

Watcom C/C++ 10 и оригинальные исходники Duke Nukem 1.5

Запустить сборку проще всего из Dosbox, распаковываем архив на диск и переходим в каталог, затем вводим:

dosbox .

Таким образом эмулятор запустится с текущим каталогом в качестве диска С: Затем вызываем скрипт для установки переменных окружения:

WATCOM\SETVARS.BAT

Переходим в каталог с исходниками движка и запускаем сборку проблемного A.ASM:

CD DUKE3D\BUILD\SRC
WASM A.ASM

Ошибок не будет и в результате появится тот самый A.OBJ — причина всех бед и несчастий при сборке Duke Nukem 3D.

Так это выглядит в действии:

Все, дальше достаточно скопировать полученный A.OBJ к себе и пересобрать DUKE3D.EXE — получим наконец нормально работающую игру времен моего детства.

Эпилог

На этом завершается «легенда о хардкоре» — удивительном компиляторе Watcom с непростой судьбой и туманными перспективами.

Хотя статья создавалась в первую очередь ради знакомства читателей, не заставших «те времена» со этим интересным и уникальным проектом, прекрасно понимаю что игра «Duke Nukem 3D» также станет для многих открытием.

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

Для примера, активно развивается проект EDuke32 — современная версия движка «Build», поддерживающая не только «Duke Nukem 3D», но и многие другие игры, c поддержкой современных ОС, готовыми сборками и сильно улучшенной графикой — все как вы любите.

Спонсоры

Оригинал статьи опубликован на Хабре.

На дворе непростой 2026, по всему миру волнами идут нехорошие события, что отражается и на нашем родном ИТ:

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

На фоне всех этих печальных событий, многие (даже опытные и достойные) люди сейчас теряют работу в ИТ, что вызывает у тех кто пока остался нездоровый энтузиазм и даже злорадство.

Популярно объясняю, почему все же не стоит радоваться чужому горю.

Веселое прошлое

Если вы вдруг забыли, в 2008м году в мире тоже бушевал финансовый кризис, который докатившись до России вызвал (кто бы мог подумать).. повальные сокращения в ИТ-отрасли.

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

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

(нач. отдела)

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

— И просить повышения зарплаты.

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

(автор) 

— Если кризис затянется и отрасль окончательно загнется — будем заказывать разработку у индусов, как в каком-нибудь Гондурасе.  

Понимаю что не нравится тратить время на собеседования идиотов, но они (идиоты) пока хотя бы есть. Есть этот «человеческий материал», из которого при желании можно что-то вылепить.

(нач. отдела)

— Что ты там лепить собрался? Если человек приходит и даже не знает как работает многопоточность в джаве.. О чем с ним разговаривать?

Тут надо заметить, что сам автор тоже не знает как на самом деле работает многопоточность, несмотря на 26 лет практики и владение Java, C, C++, C# и кучей других языков и технологий.

Просто чтобы это осознать ушло 26 лет, по началу-то я тоже заявлял, что все знаю и умею.

(автор) 

— А с индусами что будете делать? Хинди учить?

(нач. отдела)

— Ну индусы нас точно не заменят, они далеко, имеют серьезные культурные различия и все такое. Так что жить мы с тобой будем только лучше, из-за снижения конкуренции. Что до остальных — туда им и дорога. Сами виноваты.

(автор) 

— Не понимаю, если компания в которой человек просто работал обанкротилась — в чем его вина?

(нач. отдела)

— Ну ведь он сам туда устроился? Сам. Значит не умеет выбирать подходящие места для работы. Значит дурак.

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

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

Ну а банк через несколько лет купили и поглотили конкуренты, полностью заменив весь ИТ-департамент.

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

Веселое настоящее

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

И то только по предварительной записи.

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

Но еще больше я рад за IT, потому что там стало одним случайным человеком меньше.

Предполагается, что озвучивает это состоявшийся профессионал, который давно и успешно работает в ИТ, а ныне радеет за чистоту нации отрасли.

Тогда, в далеком 2008м мне не удалось отстоять свою точку зрения, сказалась разница в возрасте и жизненном опыте. Ну и конечно социальное положение — спорить с руководством занятие все же не особо перспективное.

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

Поехали.

Действительно, многим профессионалам не нравится повышенный интерес к ИТ-отрасли среди плебеев широких масс — в интернете куча статей, роликов и постов, высмеивающих недалеких «вкатунов в ИТ» и продавцов ИТ-курсов, откровенный глумеж над «джунами» и прочее подобное.

Все это понятно и предсказуемо, но есть нюанс:

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

Видно это далеко не только по Хабру, точно также дела обстоят и на других (в том числе англоязычных) площадках.

Соотношение везде примерно одинаковое:

на одного реального специалиста, который действительно работает по профилю приходится несколько тысяч заинтересованных «зрителей».

Даже на профильных ресурсах, посвященных например ретро-компьютерам или редким языкам программирования, где по-идее должны обитать только самые упертые профи сохраняется такое же соотношение.

Веселое будущее

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

Нет дурацких постов про «вкат в ИТ за месяц без образования» с сотнями комментариев и смешных мемов про тупых рекрутеров.

Представили? Обрадовались? Вздохнули с облегчением?

А теперь вопрос:

что в таком случае станет с вами — профессионалами и ИТ-экспертами?

Кому будет нужна экспертиза, которая работает лишь в сравнении с обывателями и кто в принципе сможет оценить вашу гениальность в таких непростых условиях? Жена и мама?

Кому вы сможете доказать свою ценность вне отрасли? Кто заплатит за вашу работу, ценность которой внезапно стала сомнительной?

Понимаю, что для многих это станет открытием: 

«экспертность» это всегда внешняя оценка, возможная только внутри своей отрасли.

Нет отрасли — не будет и экспертов.

А ведь утрата массового интереса к ИТ, разочарование и показательная «отмена» закончится именно этим — отрасль просто перестанет существовать.

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

Повторюсь для тех кто не осознал:

это происходит не потому что сам Василий — плохой, хреново учился или работал, просто обществу внезапно стали не нужны профессионалы в этом конкретном деле.

Как это было с физиками-ядерщиками, да.

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

Будет примерно как с футболом:

импортированные за безумные деньги иностранные игроки, выпускаемые на поле под российским флагом.

Собственно что-то подобное уже происходило в начале 90х — на заре развития отечественного ИТ, когда для любого сколь-нибудь серьезного проекта вызывали дорогих иностранных специалистов из IBM и Microsoft, а местным талантливым Василиям открыто говорили, что «ты только лаптем щщи хлебать умеешь».

Хотя буквально за пять лет до этого самой массовой профессией в стране была профессия инженера.

Так стоит все это повторять?

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

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

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

Или такая перспектива еще не очевидна?

Немного понимаю в компьютерах

Представьте себе супермена со сверхчеловеческими способностями, умеющего летать на пердючем пару и стрелять лучами из глаз, но вся сила которого.. мгновенно пропадает стоит только окружающим перестать в него верить — вот это и есть та самая «экспертиза в ИТ»:

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

На этой вере в высокотехнологичное волшебство как ни крути все ИТ и держится, время от времени обновляя вывеску.

Даже моя собственная деятельность — все эти крутые статьи на технические темы, была бы невозможной без постоянного интереса к ИТ от простых обывателей — от тех самых «вкатунов», выпускников курсов, «джунов» и прочих слесарей-сантехников, для которых работа в ИТ так и осталась мечтой.

Да, коллеги по отрасли тоже проявляют определенный интерес к моей работе, но при соотношении «1 профи на 10000 идиотов любителей» все это бы просто не имело никакого смысла.

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

Но дворовая игра в футбол это тоже футбол, пусть и любительский. И только из любительства появляются профессионалы.

Хотите новых Роналду и Месси? — заставляйте всю страну играть в дворовый футбол. По-другому, увы, не работает.

Нет, это не очередная история времен бурной молодости автора и на дворе все также 2026й год а не начало 90х. Но даже в 21м веке с ИИ, роботами и Илоном Маском в сети остались удивительные места, где время остановилось:

в ходу консольные терминалы и модемы а экран украшает ASCII-графика.

Именно такие места мы сейчас посетим — добро пожаловать в удивительный мир современных BBS!

Справка для непричастных

Цитируя погибающую википедию:

BBS (bulletin board system — электронная доска объявлений, «борда») — широко использовавшийся во времена раннего интернета, способ общения пользователей компьютеров через коммутируемые телефонные сети.

Сухое описание выше хотя и раскрывает суть явления, но не дает всей глубины картины, поскольку BBS в конце 80х — начале 90х стали культурным феноменом, сильно повлияв на процессы коммуникации между людьми.

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

Про эпоху BBS даже успели снять трехсерийный документальный фильм, ныне доступный для свободного скачивания.

Исторически BBS служили двум важным целям: пообщаться с другими пользователями путем текстовых сообщений и обменяться файлами.

Не просто скачать что-то с борды, а именно обменяться:

на скачивание выставлялся лимит, который можно было поднять что-то загрузив обратно, причем чтобы не заморачиваться — рейтинг считался от размера загруженного.

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

9600 бод и все-все-все

История BBS в нашей стране весьма обширна и тесно связана с ФИДО, поскольку большая часть борд были одновременно фидошными нодами, а звонившие юзеры — пойнтами.

И сама фидошка и некоторые действующие отечественные борды до сих пор существуют, но ввиду обширности этой темы — оставлю их для следующих интересных статей.

А пока можете насладиться бессмертными произведениями Андрея Щербакова, неплохо передающими ту самую атмосферу.

Подключение

Чтобы с комфортом бороздить просторы терминального киберпространства, нужен специальный лед софт, поддерживающий дедовские трюки с терминалом и ASCII-графикой.

Конечно подключиться возможно и с помощью стандартного telnet или ssh-клиента, которые присутствуют в любой современной ОС, но тогда вместо стильной графики вы увидите лишь страшные «кракозябли».

Типа таких:

Для этой статьи автор использовал наверное самый популярный и известный среди пожилых кибервоинов терминал:

Как шутят его авторы:

SyncTERM — giving a fairly small group of people a huge amount of joy.

Терминал присутствует в виде готового пакета во многих дистрибутивах Linux и разумеется во всех BSD, одну из которых автор и использовал для создания этой замечательной статьи:

Хотя разумеется существуют сборки и для более обывательских Mac и Windows, так что никто не уйдет огорченным.

Простой случай

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

syncterm telnet://www.theunderground.us:10023 

Появится окно, в котором через какое-то время отобразится ASCII-лого удаленной BBS-системы со стильным приглашением:

Сложный случай

В сложном случае придется обходить блокировку доступа для РФ, поскольку даже сисопы последних сохранившихся BBS почему-то принимают отечественных пользователей за злобных хакеров.

Так что используем трюк с ncat из пакета известного сканера открытых портов nmap, сначала пробросив порт подключения через прокси:

ncat -l 127.0.0.1 2323 -c "ncat --proxy-type socks5 --proxy xx.xx.xx.xx:3145 blackflag.acid.org 23"

А затем указав syncterm подключиться через этот порт:

syncterm telnet://127.0.0.1:2323

Вот таким нехитрым способом попадаем в Зазеркалье для избранных, без всяких белых кроликов.

Кибердека

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

Иногда на свет появляются настоящие хтонические техношедевры шального инженерного воображения:

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

Альтернативным вариантом кибердеки (из достойных) является использование редкого или винтажного железа в качестве терминала для подключения к BBS. Характерный пример:

К сожалению автор не имеет столько свободного времени недостаточно элитен чтобы собрать собственную кибердеку, поэтому использовал один из своих винтажных ноутбуков с FreeBSD, на котором и создавалась эта статья.

Так выглядит подключение к современной BBS с моего боевого аппарата, заставшего интернет без Цукерберга и его позорного детища:

Разобравшись с подключением и кибердеками, переходим к следующему важному этапу.

Регистрация

Почти все BBS после подключения требуют (пусть и условную) регистрацию, но ничего сложного тут нет и капчу проходить не придется:

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

Так что смело вводим в поле адреса известное:

221B Baker Street

И не менее известное jeevacation@gmail.com в качестве почты — все будет замечательно работать.

Списки BBS

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

Вот вам несколько таких сайтов-каталогов для начала погружения в терминальное киберпространство:

• 8-Bit Boyz
• MICHAEL'S BBS LIST
• Telnet BBS Guide

Отдельно доставляет этот сайт, построенный в стиле корпоративного портала, но при этом целиком посвященный олдскульным бордам.

Там же реализован виджет с отображением всех действующих BBS на планете:

Помимо каталогов, доступных из интернета, на каждой работающей BBS можно найти раздел со списком других борд, часто менее известных и с более редким контентом и обитателями. Так это выглядит:

Теперь показываю что находится внутри современных BBS, поскольку мало у кого из читателей хватит времени и терпения для всех этих приседаний с syncterm, подключением и регистрацией.

The Vortex

Название борды: The Vortex
Подключение: Telnet
Telnet: telnet://vortexbbs.com
Сисоп: Haakon & Arelas
Местонахождение: Charlotte, NC
Движок BBS: Mystic

Сайт: http://vortexbbs.com

Цитируя оригинальное описание:

An oldschool board from the 1997 art scene in the 864 area. Totally artd out and modded. Original in-house developed apps. Unique BBS experience, classic and modern..

Борда забита под завязку олдскульным ASCII-артом, демо и всем подобным, а судя по активным перепискам — борда очень даже живая:

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

Так выглядит раздел с файлами, в который простых пользователей с порога не пускают:

Из смешного и курьезного, нашлось вот такое сообщение времен выборов 2020 года в США:

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

Но едем дальше.

DIGITAL WARFARE

Название: D i G i T A L WARFARE
Подключение: Telnet
Telnet: telnet://bbs.digital-warfare.net:1337
Сисоп: CrackerTron
Местонахождение: Underground
Движок BBS: Mystic

Перед вами реинкарнация старой и известной борды начала 90х, переделанная на современные технологии.

Так выглядит приветственное сообщение для новых юзеров:

Тут хранится 2 терабайта файлов времен расцвета сцены:

ASСII-арт, различные демо, электронные журналы и конечно варез тех лет.

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

В свои лучшие годы эта борда даже имела отдельное интро:

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

Главное меню борды:

Еще тут весьма активные переписки юзеров:

При должном уровне английского можно пообщаться с крайне интересными персонажами.

С российских IP пока пускают, но в «intrusion attempts» уже замечают:

Adept BBS

Название: Adept BBS
Подключение: Telnet
Telnet: telnet://adeptbbs.com
Сисоп: Ragtop
Местонахождение: Louisville, KY
Движок BBS: Worldgroup 3.3

Оригинальное описание из BBS-списка:

Old school Worldgroup board in Louisville, Ky. Original beta testers for MajorMUD along with many other games, including Tradewars and Swords of Chaos.

Борда посвящена целиком текстовым онлайн-RPG — MUD, под эту тему тут и доступные файлы и все обсуждения.

Приветственное сообщение для новых юзеров:

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

Раздел с файлами:

Backwood Realm BBS

Название: Backwood Realm BBS
Подключение: Telnet, SSH
Telnet: telnet://bwrbbs.ddns.net

SSH: ssh://bwrbbs.ddns.net
Сисоп: Tim Wray
Местонахождение: Bedford, Indiana, USA
Движок BBS: Synchronet

Еще одна реинкарнация небольшой домашней борды 90х:

Обновленная версия работает с 2008 года с доступом через telnet/ssh и посвящена текстовым RPG, собственно на борде установлены LORD и LORD2, выглядит это как-то так:

У борды есть даже собственная страничка на Фейсбуке, довольно свежая.

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

Приветственное сообщение для новых юзеров:

Раздел с файлами:

BLACK FLAG BBS

Название: BLACK FLAG BBS
Подключение: Telnet
Telnet: telnet://blackflag.acid.org
Сисоп: Hawk Hubbard
Местонахождение: Hudson, Florida
Движок BBS: Mystic
Вот оно:

For over 20 years it has been the lucky recipient of the finest working screens from the worlds best ANSi – Ascii and RIPScrip artists. We would like to list and thank those over the years that have contributed to the boards great success

Наконец-то перед вами настоящая тру-хардкор-андеграунд борда, из палаты мер и весов, можно сказать эталон.

Борда сама по себе — настоящее произведение искусства, при этом является центром притяжения для сценеров и арт-групп со всего мира.

The board is mainly an underground ACiD art show board since 1995 and a hub for various modding groups over the years.

Записал небольшой ролик с демонстрацией внутренних интерфейсов:

К сожалению российские IP тут забанены и при попытке подключения из России борда обрывает соединение, поэтому придется использовать метод обхода с ncat, описанный выше.

Зато целых две галереи с консольным артом сразу в главном меню:

Стрим новостей Fox News внутри терминальной BBS — теперь вы видели все:

Так выглядит раздел с файлами:

Самое неожиданное место для поиска материалов по Android:

Капитанский журнал, где можно оставить сообщение:

Одна из самых эпических работ:

BlackICE

Название: BlackICE
Подключение: Telnet
Telnet: telnet://blackice.bbsindex.de
Сисоп: -
Местонахождение: Duesseldorf, Germany
Движок BBS: Mystic

Это первая борда на моей памяти, у которой есть собственный канал на Youtube:

The Newscenter is one of the special features of the BlackICE BBS. Read News, Tweets and much more. You can also send tweets from the Board! The FileArea counts more than 222.000 files and is one the biggest in the BBS Scene. WHQ BBSnet, DoorGames, Many MsgNetworks, Pointfriendly and more! The BlackICE BBS receives an average amount of 300+ calls per month and process 1000+ Messages per day.

Тусовочное место для киберэлиты с кучей интеграций в современный интернет, так выглядит приглашение для входа:

Приветственное сообщение для новых юзеров также на двух языках:

Главное меню:

Так выглядит раздел с файлами, специально записал в динамике:

Борда имеет множество точек присутствия в разных сетях, от такого изообилия дергается мой старый глаз, повидавший многое:

Прямо отсюда можно попасть на несколько других борд:

Есть даже встроенный терминал для подключения к другим системам:

С российских IP пускают, так что можно не заморачиваться проксями.

Эпилог

Я показал тут лишь малую (и самую безобидную) часть всей этой BBS-тусовки, на самом деле действующих борд гораздо больше. На свете существуют тысячи разнообразных BBS с непугаными сисопами и самым отбитым контентом, который давным давно заблокирован в большом интернете.

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

Так что включайте свои кибердеки и вперед — покорять настоящий современный андеграунд!

Спонсоры

Оригинал статьи опубликован на Хабре.

Хром

Браузер Chrome, созданный и разрабатываемый корпорацией Google давно стал главным инструментом для большинства пользователей компьютерной техники:

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

Исключения редки, это продукция Apple со своим собственным браузером Safari, медленно умирающий Firefox и совсем уж сказочная альтернативщина.

Два вечных конкурента в виде браузеров Opera и Internet Explorer сдались и ныне используют под капотом одинаковый движок от Chrome.

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

Даже эта статья создавалась с помощью браузера Chrome:

Скорость

Конечно высокооплачиваемые разработчики самого популярного браузера на планете, щедро финансируемые «корпорацией добра» — не полные идиоты и разбираются в вопросах производительности собственного продукта гораздо лучше автора.

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

Чем мы сейчас и займемся.

Применимость

Описываемые ниже инструкции — для десктопной версии браузера Chrome и с учетом специфики трех разных операционных систем: Windows, Linux и FreeBSD.

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

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

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

Производительность

Я использую Chrome на ноутбуках с момента его появления и часто работаю «в поле» — от батареи и без подключения к розетке. Помимо браузера на машине постоянно присутствуют еще несколько тяжелых приложений — в первую очередь среды разработки и разнообразные редакторы.

Все это в итоге формирует следующий набор требований:

1. браузер не должен нападать на человека отбирать себе все доступные ресурсы;
2. браузер не должен «сжирать» батарею ноутбука;
3. браузер должен продолжать работать с современными сайтами, сохраняя отзывчивость интерфейса.

Время «холодного запуска» и скорость отрисовки страниц при таких вводных разумеется могут пострадать, но будут оставаться в пределах разумного.

Версии Хрома

Чтобы не было путаницы, стоит сразу прояснить ряд нюансов с названиями продуктов и используемыми терминами.

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

Именно эта версия доступна для скачивания с официального сайта и имеет максимальную интеграцию с сервисами и другими продуктами Google.

Открытая часть браузера Chrome (движок) называется «Chromium» и с точки зрения обычного пользователя никак не поставляется, поскольку Chromium предназначен в первую очередь для технических специалистов, участвующих в процессе разработки и тестирования.

Chromium по-умолчанию имеет минимальную интеграцию с сервисами Google, что например не позволяет без дополнительных шагов устанавливать расширения из официального магазина.

Наконец существует проект «Ungoogled Chromium», авторы которого постарались удалить из Chromium абсолютно все интеграции с сервисами Google и все закрытые инструменты сборки.

Ungoogled Chromium за последние годы набрал немалую популярность, поэтому активно используется в BSD-системах и дистрибутивах Linux, ориентированных на безопасность.

Поскольку использование сервисов Google в наше непростое время может приводить к непредсказуемым проблемам и сбоям подключения, я буду использовать для всех оптимизаций Ungoogled Chromium либо просто Chromium, но не официальный Google Chrome.

Тем не менее, для простоты повествования в статье используется термин «Chrome» в качестве обозначения браузера, поскольку описываемые методы оптимизации полностью совпадают и частично применимы и к другим браузерам на основе Chromium.

Тестовая среда

Для статьи использовались современные 64-битные сборки браузера, с версиями начиная с 147 и выше:

147.0.7727.101 (Official Build) (64-bit)

Ungoogled Chromium имеет свою собственную нумерацию версий, для статьи использовались версии 137 и выше:

Версии разные под разными операционными системами, но самые последние на момент написания статьи.

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

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

Эти весьма устаревшие по любым меркам (особенно второй) машины станут отличным тестовым полигоном для демонстрации результатов всех моих вивисекций оптимизаций.

Оптимизация

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

хитрые настройки, хитрые плагины и хитрое окружение. 

Все ради того чтобы крутить ленту каких-нибудь Reddit/LinkedIn без зависания браузера и 100% загрузки системы.

Поехали.

Linux-версия

Так исторически сложилось, что я использую множество разных Linux-дистрибутивов в своей непростой деятельности:

Debian, Ubuntu, Manjaro, Mageia, Calculate  — и это только на хосте.

Описанные ниже инструкции работают на всем этом зоопарке и по своей сути применимы для любого окружения на базе Linux, везде где используется браузер Chrome.

Замечу, что Calculate Linux (на базе Gentoo) использует OpenRC вместо systemd, поэтому там не используется трюк с systemd-run.

Начнем со скрипта запуска браузера, в котором специальными параметрами включаются или отключаются разные хитрые опции, а также используется специальное окружение:

#!/bin/bash

systemd-run --user --slice=chromium.slice chromium \
    --enable-features=VaapiVideoDecoder,VaapiVideoEncoder \
    --enable-gpu-rasterization \
    --disable-gpu-compositing \
    --enable-zero-copy \
    --disable-background-networking \
    --disable-client-side-phishing-detection \
    --disable-prompt-on-repost \
    --disable-sync \
    --metrics-recording-only \
    --no-first-run \
    --safebrowsing-disable-auto-update \
    --ignore-gpu-blocklist \
    --renderer-process-limit=4 \
    --disable-smooth-scrolling \
    --wm-window-animations-disabled \
    --animation-duration-scale=0 \
    --disable-spell-checking \ 
    --disable-features=WhatIsNewPage,Promotions,LensOverlay \       
    --enable-unsafe-swiftshader "$@"

Сохраняете текст выше в какой-нибудь /opt/own/bin/chrom, выставляете бит запуска:

chmod +x /opt/own/bin/chrom

И используете этот скрипт для первого запуска браузера.

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

Теперь рассказываю страшную сказку про «прожорливый» Chrome и пропавшую память, точнее про эту интересную строку:

systemd-run --user --slice=chromium.slice chromium

Дело в том, что у браузера Chrome есть дурная привычка считать весь компьютер своей собственностью и захватывать максимум доступных ресурсов — всю свободную память и все доступные процессоры и ядра.

Пока вы работаете на сервере современной машине с кучей памяти, не держите открытыми сотни вкладок с 3D-графикой а конкуренцию браузеру за доступные ресурсы составляет только офисный пакет — проблемы нет.

Но стоит лишь немного просесть по мощности используемого оборудования или доступным ресурсам для более прожорливых программ (привет Davinci Resolve) и любимый браузер от «корпорации добра» немедленно показывает звериный оскал свое истинное лицо.

В случае ноутбука (тем более мощного) проявляется еще один дурной эффект:

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

Так что становится жизненно необходимым сажать браузер на ресурсную диету с помощью systemd и функционала cgroups.

Делается это в современных Linux-дистрибутивах довольно просто, для начала создаем файл ~/.config/systemd/user/chromium.slice со следующим содержимым:

[Slice]
MemoryAccounting=yes
MemoryHigh=1G
MemoryMax=1.5G
MemorySwapMax=3000M
CPUAccounting=true
CPUQuota=70%

Помимо очевидных лимитов на объем используемой памяти (MemoryHigh и MemoryMax), тут еще задается квота на загрузку процессора (CPUQuota), что не дает поднять ее выше заданного лимита — 100% загрузку CPU от процессов Chrome вы больше не увидите.

Теперь самое важное:

все указанные лимиты применяются ко всем дочерним процессам, которые запускает Chrome во время работы.

По сути создается ограниченный по ресурсам контейнер, внутри которого запускается браузер.

Ну и сам запуск с помощью черной магии systemd-run и указания слайса:

systemd-run --user --slice=chromium.slice chromium

Аналогичным образом можно ограничивать по ресурсам любые другие «жирные» приложения, например Telegram, который в последних версиях повадился генерировать 100% загрузку процессора по любому поводу.

Замечу, что сей хитрый трюк работает и с приложениями, работающими внутри AppImage или snapd-пакетов, так что с его помощью замечательно урезаются аппетиты версий Chrome/Chromium в Ubuntu/Manjaro, управляемые snapd.

Отключение анимации

Существует одно интересное расширение для Chrome, позволяющее отключать анимированные картинки на всех страницах:

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

Нетрудно догадаться, что этим сильно снижается нагрузка на CPU/GPU (особенно в случае устаревшего оборудования), с чего происходит серьезная экономия заряда батареи.

Так что очень рекомендую к использованию.

Ungoogled Chromium и установка расширений

К сожалению для установки расширений из официального магазина для «левого» Ungoogled Chromium и (совсем недавно) официального Chromium стало необходимо специальное расширение.

Без которого вас обрадуют сообщением об ошибке:

CRX_REQUIRED_PROOF_MISSING

А кнопка установки в интерфейсе магазина окажется скрытой.

В качестве альтернативного варианта можно использовать специальный сайт от авторов расширения, который позволяет скачать пакет с расширением .crx и установить его локально в вашем браузере.

Теперь переходим к самому интересному — к параметрам запуска.

Параметры Chrome

У браузера Chrome есть огромное количество разнообразных параметров запуска, как документированных так и не очень.

Часть из них дублируется во внутреннем служебном интерфейсе chrome://flags/ — может быть задана не из командной строки, а с помощью интерфейса браузера, часть — нет.

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

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

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

Так выглядит их небольшая часть в динамике:

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

Поехали.

--enable-features=VaapiVideoDecoder,VaapiVideoEncoder

Ключ --enable-features= как нетрудно догадаться из названия используется для принудительного включения опций браузера.

В данном случае принудительно включаются кодеки для аппаратного декодирования видео, работающие на базе Video Acceleration API (VAAPI).

По-умолчанию, если библиотека VAAPI в системе не установлена либо работает неправильно, браузер автоматически переключится на медленный программный кодек, с чего будет сильно нагружаться процессор при проигрывании видео.

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

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

--enable-gpu-rasterization 

Данный ключ принудительно включает аппаратную отрисовку страниц с помощью GPU:

Chrome 37 introduced a GPU rasterizer. When enabled, some paint workloads can go from 100ms/frame to 4-5ms/frame.

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

--disable-gpu-compositing 

Принудительное отключение GPU-реализации композитора страниц.

Актуально для сильно устаревшего оборудования, вроде моего Asus F3KE, поскольку GPU-композитор на нем порождает визуальные артефакты и искажения:

--enable-zero-copy 

Согласно строчке с описанием в исходном коде браузера:

Enable rasterizer that writes directly to GPU memory associated with tiles.

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

--disable-background-networking 

Запрещает браузеру использовать фоновые сетевые запросы, например проверку обновлений для установленных расширений.

--disable-client-side-phishing-detection 

Отключает фоновую проверку сайтов на фишинг.

Этот параметр вроде как удален в новых версиях браузера, но все еще часто встречается в различных руководствах и материалах.

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

--disable-prompt-on-repost 

Отключает дурацкое предупреждение о повторной отправке формы:

 --disable-sync 

Отключает облачную синхронизацию учетной записи Google.

Актуально только для обычного Chromium, для ungoogled-версии не используется, поскольку функционал глобальной учетной записи там вырезан.

--metrics-recording-only 

Указывает браузеру только записывать отчеты с метриками производительности, но запрещает отправлять их на сервера Google.

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

--no-first-run 

Отключает приветственный диалог при первом запуске браузера.

--safebrowsing-disable-auto-update 

Отключает автоматическое фоновое обновление баз для «Safe Browsing» — специального сервиса Google для защиты от фишинга и подозрительных сайтов.

Актуально для обычного Chromium, поскольку в ungoogled-версии функционал «Safe Browsing» удален.

--ignore-gpu-blocklist 

Натурально заставляет браузер «работать на дровах» — использовать неподдерживаемое и сильно устаревшее оборудование для аппаратного ускорения.

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

--renderer-process-limit=2 

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

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

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

--disable-smooth-scrolling 

Просто «имба» за которую вы потом будете благодарить — параметр отключает плавную прокрутку в браузере, которая очень сильно влияет на скорость при работе на слабом или устаревшем оборудовании.

Влияет настолько сильно, что разницу становится видно визуально после перезапуска.

--wm-window-animations-disabled 

Отключает всю анимацию в интерфейсе браузера.

--animation-duration-scale=0 

Переопределяет длительность воспроизведения CSS-анимации, значение 0 означает полное отключение, но работает к сожалению только для элементов интерфейса самого браузера, не для страниц.

--disable-spell-checking 

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

--enable-unsafe-swiftshader

Еще один важный параметр, который разрешает использование «небезопасного» программного рендера WebGL, что позволяет использовать 3D-графику в браузере даже на устаревшем оборудовании, которое не поддерживает современное Vulkan API.

--disable-features=WhatIsNewPage,Promotions,LensOverlay,OptimizationGuideOnDeviceMode

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

В данном случае отключаем встроенную рекламу новых фич браузера, которые вылезают при обновлениях и очень сильно бесят отвлекают.

Актуально только для обычного Chromium, поскольку в ungoogled-версии все эти радости вырезаны.

Хром и Windows

Я использую Windows 11, 10 и 7 на рабочих станциях а также множество разных виртуальных машин с серверными версиями Windows.

Оптимизации актуальны только при использовании браузера на рабочей станции, поэтому в качестве тестовой среды будут выступать только три клиентских версии Windows: 11, 10 и 7.

Скрипт запуска выглядит следующим образом:

chrome.exe --enable-features=VaapiVideoDecoder,VaapiVideoEncoder^
    --disable-features=WhatIsNewPage,Promotions,LensOverlay^
    --enable-gpu-rasterization^
    --disable-gpu-compositing^
    --enable-zero-copy^
    --disable-background-networking^
    --disable-client-side-phishing-detection^
    --disable-prompt-on-repost^
    --disable-sync^
    --metrics-recording-only^
    --no-first-run^
    --safebrowsing-disable-auto-update^
    --ignore-gpu-blocklist^
    --renderer-process-limit=4^
    --disable-smooth-scrolling^
    --wm-window-animations-disabled^
    --animation-duration-scale=0^
    --enable-unsafe-swiftshader %*

Сохраняете текст выше в файле run.cmd, кладете в каталог рядом с chrome.exe и используете для первого запуска.

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

Замечу лишь что символ ^ — аналог \ в UNIX-мире и используется для переноса длинных строк в командных скриптах под Windows.

Поскольку в последние версии и Chrome (и даже Chromium) под Windows авторы напихали AI-фич под завязку, на моих рабочих станциях используются только и исключительно Ungoogled-сборки.

Chrome и старые Windows

Google перестала поддерживать работу на Windows 7 для Chrome/Сhromium начиная с 2023го года, поэтому если у вас еще осталась живая «семерка» и необходимо использовать современный браузер — ждите мою следующую статью, в которой описан процесс бекпортирования современной версии браузера в Windows 7.

Цитируя одну известную шутку:

В случае с бекпортированием Chrome на устаревшие версии Windows именно так и произошло:

стоило только начать изучать вопрос и подбирать варианты — немедленно нашелся репозиторий, с бекпортами последних версий Chrome.. под Windows XP!

Windows XP вышла в далеком 2001м году, если кто вдруг забыл и процесс бекпортирования под настолько старую ОС был сильно сложнее чем например под Windows 7.

Вот тут выложены готовые сборки браузера под Windows XP с поддержкой аппаратного ускорения (!) — невероятный хардкор.

Chrome и FreeBSD

Наконец последним разделом описываю то, с чего началась эта статья в далеком 2023м году:

оптимизация работы браузера Chrome под FreeBSD на очень сильно устаревшем оборудовании.

«Очень сильно устаревший» — про тот самый Asus F3KE из 2007 года, спасенный автором от достойного погребения:

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

Так выглядит скрипт запуска:

#!/usr/local/bin/bash

source ~/.exports.sh

/usr/local/bin/ungoogled-chromium
    --enable-features=VaapiVideoDecoder,VaapiVideoEncoder \
    --enable-gpu-rasterization \
    --disable-gpu-compositing \
    --enable-zero-copy \
    --disable-background-networking \
    --disable-prompt-on-repost \
    --metrics-recording-only \
    --no-first-run \
    --ignore-gpu-blocklist --renderer-process-limit=2 \
    --wm-window-animations-disabled \
    --animation-duration-scale=0 \
    --enable-unsafe-swiftshader "$@"    

Довольно давно в FreeBSD используется ungoogled-версия браузера, поэтому были убраны параметры для функционала из обычного Chromium, который был вырезан в ungoogled-версии.

Строка:

source ~/.exports.sh

на самом деле скрывает портал в ад отдельный механизм повторного использования сессии DBus, файл ~/.exports.sh создается таким специальным скриптом:

#!/usr/local/bin/bash

FF=0

if [[ -z $DBUS_SESSION_BUS_ADDRESS ]]; then
    lines=$(pgrep "dbus-daemon" -u "$USER" | (while read -r line
    do
        echo $line
        exp=`procstat -h -e $line` 
        if [[ "$exp" == *"DBUS_SESSION_BUS_ADDRESS="* ]]; then
	    echo "DBus session found"
	    exp2=`echo $exp |sed 's/.*DBUS_SESSION_BUS_ADDRESS=\([^ ]*\).*/\1/'`
    	    echo export DBUS_SESSION_BUS_ADDRESS="$exp2" > ~/.exports.sh
    	    FF=1
    	    break
        fi
    done; echo $lines) )
    echo $FF
    if [[ "$FF" = 8 ]]; then
       echo "DBus session not found, starting.."
       dbus_out=`dbus-launch`
       echo $dbus_out > ~/.exports.sh
    fi
    if [[ -f ~/.exports.sh ]]; then
        source ~/.exports.sh
    fi
fi

Этот скрипт натуральным образом ворует сессию работы с DBus, забираясь для этого в окружение запущенного процесса (да, так можно было) — все ради того чтобы ее не дублировать и не запускать процесс dbus-launch повторно.

Помимо приседаний с параметрами, в версии для FreeBSD также используется описанное выше расширение браузера для отключения анимации, а вместо изоляции через cgroups используется более простой вариант со сниженным лимитом на количество запущенных процессов рендера:

 --renderer-process-limit=2

Чего вполне достаточно для комфортной работы.

За кадром

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

Они также применимы ко всем версиям и вариациям браузера и работают на всех операционных системах.

--profile-directory=test-profile

Указывает альтернативное название профиля, по-умолчанию он называется Default и находится в каталоге пользователя.

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

--single-process

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

Этот весьма опасный (во всех смыслах) параметр переключает Chrome в нестандартный режим работы, при котором браузер не порождает отдельные процессы на каждую вкладку.

К сожалению такой режим работы является весьма нестабильным и браузер будет падать, особенно на сложном контенте и с большими расширениями вроде AdBlock.

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

--disable-features=UseSkiaRenderer

Отключает современный бекэнд Skia Renderer, используемый в браузере для отрисовки практически всей графики:

Chrome uses Skia for nearly all graphics operations, including text rendering. GDI is for the most part only used for native theme rendering; new code should use Skia.

К сожалению этот параметр является обязательным если вы собираетесь использовать --single-process, думаю очевидно что скорость отрисовки страниц при этом упадет.

Эпилог

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

Поэтому с радостью почитаю про ваш опыт и применяемые практики.

Спонсоры

Оригинал статьи опубликован на Хабре.

Python — весьма занятный язык программирования с богатой историей, который сильно недооценивают многие серьезные программисты, напрасно полагая, что это «какие-то скрипты» для детей ML-щиков и тестировщиц.

Надеюсь описанное ниже даст определенное понимание, что «змеиный язык» сильно сложнее чем кажется и несет в себе множество нетривиальных нюансов.

Отказ от ответственности

Сам автор (несмотря на название статьи) всячески разделяет традиционные программистские ценности:

читаемость кода, адекватность реализации и радость применения

Поэтому заранее предупреждает, что попытка использовать описанные практики в реальном проекте может привести к серьезным проблемам со здоровьем и дальнейшим трудоустройством.

Возможно с вами даже перестанут здороваться за руку. Когда отвяжут от батареи.

Развлечение первое: Змея и Си

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

Вчера начал изучать Python и пока мне все нравится.

Хотя я давно пишу на С, некоторые вещи в Python уже кажутся проще чем в С. 

А ведь еще есть множество практик, которые легко перенести из С! Очень нравится, что тут есть циклы while и for прямо как в С. Боялся что придется опять все изучать с нуля, но оказалось что это не так. Единственное к чему пришлось привыкать, что выражения заканчиваются запятой а не точкой с запятой.

Как бы то ни было, вот мой скрипт (на Python 3.8, это всего лишь игрушечный скрипт для тестов циклов for и while). Есть идеи как можно улучшить мой код и сделать его более читаемым?

Каждый открывший этот код по ссылке, если он хоть немного понимал в программировании на Python — немедленно получал солнечный удар, разрыв мозга или сердечный приступ.

И острое желание сжечь диплом инженера, поскольку этот замечательный код ставил под сомнение границы реальности компетенции практически любого Python-разработчика.

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

#include <stdint.h>
#include <stdio.h>

#/* pre-declare types and functions */
void: (type) = (type) ("(void *)0"),
int16_t: (type) = (type) (int(16))(),
int32_t: (type) = (type) (int(32))(),
puts: ((str) := void) = (print),
printf: ((str) := void) = (puts),

#/* confirm function and variable declarations */
[[void]] = (void),
[[total]] = (int32_t),
[[i]] = (int32_t),
[[puts]] = (puts),
[[printf]] = (printf),

#/* ensure forwards and backwards compatibility */
import __future__ as __past__
#define FUTURE PAST
#define PAST FUTURE

#/* output a formatted string to stdout */
def printf(s, __VA_ARGS__) -> (void) :{
    (void) (puts((void).__mod__(s, __VA_ARGS__), end=((void).__new__)(void))),
}

#/*******************************************************
# * SUMMATION SCRIPT                                    *
# *******************************************************
# * Sum up all the natural numbers up to 6. The result  *
# * should be 0 + 1 + 2 + 3 + 4 + 5 + 6 = 21.           *
# *******************************************************/

#/* print numbers from 0 to 6 */
int32_t: i = 0,
while (i <= 6) :{
    (void) (printf(" %d\n", i)),
    (i := i + 1),
}

(void) (puts("__")),

#/* sum up numbers from 0 to 6 */
int32_t: total = 0,
int32_t: i = 0,
for (int32_t) in (i <- 0, i <= 6, ++i) :{
    (total := total + i),
}

(void) (printf("%d\n", total)),

Упреждая очевидный вопрос:

Перед вами полностью рабочий код на языке Python, не на С.

К сожалению синтаксис успел немного поменяться с 2020го и попытка запуска на современной версии Python выдаст ошибку:

Ошибку тем не менее легко исправить, убрав скобки вокруг str в двух строках. Было:

puts: ((str) := void) = (print),
printf: ((str) := void) = (puts),

Стало:

puts: (str := void) = (print),
printf: (str := void) = (puts),

После правки все отлично запускается:

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

Оригинальный разбор был также опубликован на Реддите, ниже приведен вольный перевод самых интересных фрагментов.

Начнем с банального, но далеко не всем очевидного:

#include <stdint.h>
#include <stdio.h>

Строки выше — валидные инструкции препроцессора для языка С, но для Python они являются лишь текстовыми комментариями. Так что это чистый троллинг «змеелюбов» и строки выше никак не используются в логике программы.

Следующая интересная конструкция уже сильно сложнее для понимания:

void: (type) = (type) ("(void *)0"),

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

Вот такой хитрый финт ушами, хотя далеко не последний:

int16_t: (type) = (type) (int(16))(),
int32_t: (type) = (type) (int(32))(),

Да это снова «троллинг-пародия» под код С, вызова int32_t = int() было бы достаточно. Но автор решил преобразовать 16 в int, получить тип, а затем вызвать его конструктор, что дало пустое значение этого типа.

Вызов int() даёт 0, если кто не знает.

puts: ((str) := void) = (print),
printf: ((str) := void) = (puts),

Эти две строчки идентичны, так что вся конструкция просто задаёт функцию с именем puts, которая равна print, и printf, которая также равна print.

#/* confirm function and variable declarations */
[[void]] = (void),
[[total]] = (int32_t),
[[i]] = (int32_t),
[[puts]] = (puts),
[[printf]] = (printf),

Все строки выше на самом деле кортежи (из-за запятой в конце), а сама конструкция разворачивает их на уровень выше — становится возможным обратиться к переменной по имени в двойных квадратных скобках:

Следующие интересные строки являются чистым, стопроцентным троллингом:

#/* ensure forwards and backwards compatibility */
import __future__ as __past__
#define FUTURE PAST
#define PAST FUTURE

Несмотря на то что в языке Python действительно присутствует специальная конструкция:

from __future__ import feature

указывающая компилятору на использование конструкций языка, которые еще не вошли в релизную версию, конечно же никаких «ensure forwards and backwards compatibility» нет и быть не может.

О чем и шутят пользователи Реддита, ссылаясь на «путешествия во времени»:

Следующий интересный блок, точно достойный разбора:

#/* output a formatted string to stdout */
def printf(s, __VA_ARGS__) -> (void) :{
    (void) (puts((void).__mod__(s, __VA_ARGS__), end=((void).__new__)(void))),
}

Тут переопределяется printf в виде функции, которая по идее должна возвращать строку из-за -> (void), но на самом деле возвращает None.

Поскольку такая конструкция проходит проверку типов, функция вида:

def x() -> str: 
  return None

вполне имеет право на существование и вернет тип NoneType при вызове.

Еще из интересного тут происходит вызов метода __mod__ у print, что внезапно дает подстановку значения в шаблон вроде "%d\n".

Следующий мозговыносящий для питонистов блок:

#/* print numbers from 0 to 6 */
int32_t: i = 0,

Тут создается новая переменная int32_t, у которой в качестве типа стоит i. Поскольку i был распакован конструкцией выше — все это проходит проверку типов и int32_t становится равно кортежу (0,).

А теперь самое веселое:

while (i <= 6) :{
    (void) (printf(" %d\n", i)),
    (i := i + 1),
}

Напоминаю, что это все еще стандартный Python, это не C и не Java.

Фигурные скобки тут на самом деле лишь для красоты ввода в заблуждение, поскольку будет работать и так:

def func(self): {
        print("Yo braces!")
     }

И вот так:

def func(self): 
        print("Yo braces!")     

Теперь вы знаете чем выбесить порадовать интервьюера на собеседовании.

Но вернемся к примеру с циклом.

Перед нами стандартный цикл while, в котором за каждый проход создается набор (set) из двух элементов. Первый элемент это результат вызова str(print( %d\n"%i)), второй — счетчик с именем i.

После завершения цикла, у i будет значение 7.

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

(void) (puts("__")),

Это аналог вызова str (print (__)). , который просто печатает на экране символ _. И все.

Зато тут уже настоящая жесть:

int32_t: i = 0,
for (int32_t) in (i <- 0, i <= 6, ++i) :{
    (total := total + i),
}

Да, это все еще обычный Python, без DSL и модулей расширения.

В примере выше создается кортеж вида (False, False, 7), поскольку 7 больше нуля, не меньше или равно 6 а вызов ++7 дает 7. Так что вся конструкция на самом деле аналогична привычному for _ in range(3):

Внутри цикла происходит увеличение значения переменной total на 7, 3×7 = 21, цикл отрабатывает три раза, создает три набора (set), которые равны значению total.

Ну и последнее:

(void) (printf("%d\n", total)),

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

Работа безусловно «мощи великой», но это еще не конец.

Развлечение второе: Змея-оборотень

Следующим интересным примером избытка свободного времени серьезных инженерных талантов является вот такой gist, c воодушевляющим названием evil.py.c.

Привожу его код целиком:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define __file__ __FILE__

#define import void*
#define def int
import codecs;
import os;
import subprocess;
import tempfile;

#if PYTHON
LANG = 'Python'
FROM_C = globals().get('FROM_C', False)
START = None
END = None
PYTHON_CODE = lambda x: eval(compile('if 1:\n%s' % x[2:-3], '<string>', 'exec'),
                             globals(), globals())
C_CODE = lambda *args: None
PRINT_PREFIX, PRINT_SUFFIX = ('printf("', '\\n");') if FROM_C else ('', '')
write = lambda s, *args: print('%s%s%s' % (PRINT_PREFIX, s % args, PRINT_SUFFIX))
#else
# define LANG "C"
# define START int main() {
# define END }
# define PYTHON_CODE(x)
# define C_CODE(a, b, c) b
# ifdef FROM_PYTHON
#  define PRINT_PREFIX "print(\"\"\""
#  define PRINT_SUFFIX "\"\"\")"
#else
#  define PRINT_PREFIX
#  define PRINT_SUFFIX
#endif
# define write(x, ...) printf(PRINT_PREFIX x PRINT_SUFFIX "\n", __VA_ARGS__)
#endif

START

PYTHON_CODE((""" "
    if FROM_C:
        print("#include <stdio.h>")
        print("int main() {");
" """))

write("%s: %s: Hello, world!", LANG, __file__);

PYTHON_CODE((""" "
    def decode_c(text):
        fd, out_file = tempfile.mkstemp()
        os.close(fd)

        try:
            subprocess.check_output([
                'clang', '-x', 'c',
                '-DFROM_PYTHON=1',
                __file__, '-o', out_file,
            ])
            result = subprocess.check_output(out_file)
            return result, len(result)
        finally:
            os.unlink(out_file)

    if FROM_C:
        print("}");
    else:
        codecs.register(lambda name: codecs.CodecInfo(lambda text: "",
                                                      decode_c,
                                                      name='c'))

        exec(codecs.decode(open(__file__, 'r'), encoding='c'))
" """))

C_CODE(""" ",
#if !FROM_PYTHON
    fflush(stdout);

    popen("python3.8 -c \"FROM_C=True ; __file__ = '" __FILE__ "'; "
          "exec(open('" __FILE__ "').read())\""
          "| clang -x c -o .generated-evil -",
          "r");
    system("./.generated-evil");
    unlink(".generated-evil");
#endif
," """)

END

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

Как пишет сам автор:

I regret nothing.

И я его не виню, поскольку перед нами отличный пример программы-оборотня, код которой валиден сразу для двух очень разных языков: Python и С.

Так выглядит запуск в виде скрипта Python:

А это уже компиляция с помощью clang в виде кода на С:

Но это еще не все:

если вы чего-то понимаете в Python или С — могли заметить, что код выше несколько сложноват для простого вывода строки «Hello, world!»

Даже с учетом специфики «программы с двойным дном», исходного кода все равно многовато, а еще и в описании есть загадочная строка:

Генератор, ага.

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

1. действительно печатает «Hello, world!»;
2. генерирует код для второй части, компилирует и тут же запускает.

Поэтому в выводе видны две строчки «Hello, world!» вместо одной, вторая — от запуска новой копии.

Добавлю, что в коде есть вот такое место:

popen("python3.8 -c \"FROM_C=True ; __file__ = '" __FILE__ "'; "
          "exec(open('" __FILE__ "').read())\""
          "| clang -x c -o .generated-evil -",
          "r");

Тут вшита версия Python, актуальная на момент создания проекта, но скорее всего в вашей системе не будет устаревшего Python 3.8, поэтому скрипт при попытке запуска упадет с ошибкой.

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

ln -s /usr/bin/python3 ~/.local/bin/python3.8

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

Развлечение третье: Кошмар аудитора

На этот раз постарался известный LinkedIn, подбросив мне в вентилятор ленту замечательный пост с весьма необычным кодом:

Удивительно, но код снова полностью рабочий и запускается на современной версии Python (3.13) без каких-либо правок:

Привожу исходный код c картинки выше, дабы было проще копировать и рассылать знакомым змеелюбам питонистам:

def artifact():
  def f(x): return x+1

  def gate(x):
     if x == 7:
        f.__code__ = (lambda y: f"Ω:{y*y}").__code__
     return f(x)
  return gate

g = artifact()
print(g(1),g(7),g(2))

То что тут происходит станет неприятным сюрпризом для всех, кто вынужден заниматься аудитом «змеиного кода»:

In Python, every function has an attribute called __code__.
This is the bytecode, the actual execution engine of the function.
And it can be replaced while the program is running.

По условию x == 7 происходит подмена байткода функции на лету — прямо в работающем приложении:

if x == 7:
        f.__code__ = (lambda y: f"Ω:{y*y}").__code__

Разумеется в самой технике нет ничего нового, аналогичный функционал присутствует и в Java и в C#, но только крестьянская простота с которой это происходит в Python определенно станет сюрпризом.

Заметить и отследить такое в реальном проекте весьма непросто.

Развлечение четвертое: Новый взгляд на ООП

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

class A:
    def func(self):
        print("A")

class B:
    def func(self):
        print("B")

a = A()
a.func()  # A

a.__class__ = B
a.func()  # B

В коде выше декларируются два разных, никак не связанных между собой класса:

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

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

Но вот дальше происходит «чудо чудесное»:

a.__class__ = B

Перезаписывается специальный атрибут __class__ , в качестве значения устанавливается класс B, никак не связанный с A.

Затем происходит вызов метода func, чья сигнатура полностью совпадает в обоих классах.

Да, это замечательно работает в Python, причем без каких-либо предупреждений:

Пикантности ситуации добавляет отсутствие явного вызова конструктора у класса B — представляете как весело такое ловить в реальном проекте?

Развлечение пятое: Змея и побитовый сдвиг

Самое интересное и шикарное я приберег на конец повествования, в качестве награды выжившим дочитавшим до этого места.

Итак, перед вами совершенно особенный код на Python, на котором карьеру программиста можно спокойно завершать:

(lambda _, __, ___, ____, _____, ______, _______, ________:
    getattr(
        __import__(True.__class__.__name__[_] + [].__class__.__name__[__]),
        ().__class__.__eq__.__class__.__name__[:__] +
        ().__iter__().__class__.__name__[_:][_____:________]
    )(
        _, (lambda _, __, ___: _(_, __, ___))(
            lambda _, __, ___:
                bytes([___ % __]) + _(_, __, ___ // __) if ___ else
                (lambda: _).__code__.co_lnotab,
            _ << ________,
            (((_____ << ____) + _) << ((___ << _____) - ___)) + (((((___ << __)
            - _) << ___) + _) << ((_____ << ____) + (_ << _))) + (((_______ <<
            __) - _) << (((((_ << ___) + _)) << ___) + (_ << _))) + (((_______
            << ___) + _) << ((_ << ______) + _)) + (((_______ << ____) - _) <<
            ((_______ << ___))) + (((_ << ____) - _) << ((((___ << __) + _) <<
            __) - _)) - (_______ << ((((___ << __) - _) << __) + _)) + (_______
            << (((((_ << ___) + _)) << __))) - ((((((_ << ___) + _)) << __) +
            _) << ((((___ << __) + _) << _))) + (((_______ << __) - _) <<
            (((((_ << ___) + _)) << _))) + (((___ << ___) + _) << ((_____ <<
            _))) + (_____ << ______) + (_ << ___)
        )
    )
)(
    *(lambda _, __, ___: _(_, __, ___))(
        (lambda _, __, ___:
            [__(___[(lambda: _).__code__.co_nlocals])] +
            _(_, __, ___[(lambda _: _).__code__.co_nlocals:]) if ___ else []
        ),
        lambda _: _.__code__.co_argcount,
        (
            lambda _: _,
            lambda _, __: _,
            lambda _, __, ___: _,
            lambda _, __, ___, ____: _,
            lambda _, __, ___, ____, _____: _,
            lambda _, __, ___, ____, _____, ______: _,
            lambda _, __, ___, ____, _____, ______, _______: _,
            lambda _, __, ___, ____, _____, ______, _______, ________: _
        )
    )
)

Серьезно:

если сможете что-то подобное написать — заканчивайте с программированием, круче уже не будет.

Конечно же такая работа не могла появиться случайно, а ее автор — мягко говоря не новичок в программировании.

Работа заняла первое место в конкурсе для особенных по обфускации:

got first place in this Code Golf contest to create the weirdest obfuscated program that prints the string “Hello world!”

Оригинальный код был создан еще в далеком 2014м году, для совсем забытого ныне Python 2.7. Много позже — в 2017м автор опубликовал обновленную версию для Python 3.x, которую я и запустил в современном окружении:

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

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

Конечно мало шансов увидеть подобное в реальном приложении (что радует), если только вы не занимаетесь изучением малвари. Но даже в этом случае, столь сильно обфусцированный код на Python — большая редкость.

Еще больше диких змей

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

Python's horror show

https://github.com/pablogsal/python-horror-show

Содержит коллекцию примеров «змеиного кода» с подозрительным или нетривиальным поведением, с описанием причин:

Strange and odd python snippets explained

Некоторые примеры определенно заставят икать даже опытных разработчиков:

>>> all([])
True
>>> all([[]])
False
>>> all([[[]]])
True

WTF Python!

https://github.com/satwikkansal/wtfpython

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

Here's a fun project attempting to explain what exactly is happening under the hood for some counter-intuitive snippets and lesser-known features in Python.

Это точно стоит держать в закладках, особенно если заставляют разгребать код на Python за нейросетью с горящими сроками.

В качестве примера:

Ну и в качестве «дембельского аккорда» показываю самое лютое:

International Obfuscated Python Code Competition

https://pyobfusc.com/

Отдельный конкурс, целиком посвященный обфускации кода на Python — прямой аналог классического IOCCC!

В качестве примера одна из работ-победителей:

"""ᐌ([ᐊ(ᐄ(ᐆ('print',ᐇ()),[ᐄ(ᐈ(ᐄ(ᐆ('open',ᐇ()),                   [ᐆ('__file__                           ',ᐇ()),ᐃ('r'
)],ᐉ),'read',ᐇ()),ᐉ,ᐉ)],ᐉ)),ᐊ(ᐄ(ᐆ('print',ᐇ()),ᐉ,ᐉ)),             ᐂ([ᐁ('conte'                         'xtlib'),ᐁ(
'io'),ᐁ('operator'),ᐁ('time')]),Assign([ᐆ('f',ᐋ())],ᐄ(ᐈ(           ᐆ('io',ᐇ()),                       'StringIO',ᐇ
()),ᐉ,ᐉ)),With([withitem(ᐄ(ᐈ(ᐆ('contextlib',ᐇ()),'redirect'         '_stdout',ᐇ(                     )),[ᐆ('f',ᐇ(
))],ᐉ))],[ᐂ(                                   [ᐁ('this')])])        ,For(Tuple([                   ᐆ('i',ᐋ()),ᐆ
('l',ᐋ())],ᐋ                                     ()),ᐄ(ᐆ('enum'       'erate',ᐇ())                 ,[ᐄ(ᐈ(ᐄ(ᐈ(ᐆ(
'f',ᐇ()),'g'                                      'etvalue',ᐇ())       ,ᐉ,ᐉ),'spli'               'tlines',ᐇ()
),ᐉ,ᐉ)],ᐉ),[                                       ᐎ(ᐒ(ᐏ(),ᐆ('i'        ,ᐇ())),[ᐊ(ᐄ(             ᐆ('print',ᐇ(
)),[ᐓ([ᐃ('H'                                       'ow does this'        ' code do i'           'n terms of'
' >'),ᐑ(ᐄ(ᐈ(                                       ᐆ('l',ᐇ()),'r'         'eplace',ᐇ()         ),[ᐃ(','),ᐃ(
'<')],ᐉ),-1)                                      ,ᐃ('?')])],ᐉ))           ,ᐐ()],[ᐎ(ᐒ(ᐏ       (),ᐆ('l',ᐇ()
)),[ᐊ(ᐄ(ᐆ(''                                     'print',ᐇ()),ᐉ,            ᐉ)),ᐐ()],ᐉ)]     ),ᐊ(ᐄ(ᐆ('pr'
'int',ᐇ()),[                                    ᐍ(ᐅ(ᐆ('comment'              ,ᐋ( )),ᐄ( ᐈ(   Dict([ᐃ(11),
ᐃ(12),ᐃ(13),                                 ᐃ(17),ᐃ(19)],[ᐃ(                 'no errors were silenced'
),ᐃ('no err'                           'ors were thrown'),ᐃ(                   'everything is crystal'
' clear'),ᐃ('for this code, never would have been better')                      ,ᐃ('does not apply')]
),'get',ᐇ()),[ᐆ('i',ᐇ())],ᐉ)),ᐄ(ᐈ(ᐓ([ᐃ('\x1b[32m✔ '),ᐑ                           (ᐆ('l',ᐇ()),-1),ᐃ(
'\x1b[0m__#_'),ᐑ(ᐆ('comment',ᐇ()),-1),ᐃ('.')]),'re'                               'place',ᐇ()),[ᐃ(
'_'),ᐃ(' ')],ᐉ),ᐓ([ᐃ('\x1b[91m✘ '),ᐑ(ᐆ('l',ᐇ())                                     ,-1)]))],ᐉ)),
ᐊ(ᐄ(ᐈ(ᐆ('time',ᐇ()),'sleep',ᐇ()),[ᐃ(0.3)],ᐉ                                          ))],ᐉ),ᐊ(ᐄ(ᐆ
('print',ᐇ()                                                                         ),[ᐃ('\x1b['
'0m')],ᐉ)),ᐊ                                                                         (ᐄ(ᐆ('print'
,ᐇ()),[ᐃ('W'                                                                         'ell...')],ᐉ
) ),ᐊ(ᐄ(ᐈ(ᐆ(                                                                         'time',ᐇ()),
'sleep',ᐇ())                                                                         ,[ᐃ(3)],ᐉ)),
ᐊ(ᐄ(ᐆ('prin'                                                                         't',ᐇ()),[ᐃ(
'I tried.')]                                                                         ,ᐉ))],ᐉ)""";
...;from ast                                                                         import *;ᐁ,\
ᐂ,ᐃ,ᐅ,ᐄ,ᐆ,ᐈ,                                                                         ᐇ,ᐌ,ᐉ,ᐋ,ᐊ,ᐍ\
,ᐐ, ᐎ,ᐏ,ᐒ,ᐓ,                                                                         ᐑ = alias ,\
  Import   ,                                                                         Constant  ,\
 NamedExpr ,                                                                         Call, Name,\
 Attribute ,                                                                         Load,Module\
,[], Store ,                                                                         Expr,IfExp,\
Continue,If,                                                                         Not,UnaryOp\
,JoinedStr ,                                                                        FormattedValue
exec(unparse                                                                    (fix_missing_locations
(eval(__doc__                                                                   ))))#Johannes Lippmann

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

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

Спонсоры

Оригинал статьи опубликован на Хабре.

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

Потому что в то жаркое лето я познакомился с демосценой.

История

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

мрачный подвал, старые побитые PC и Doom, Duke Nukem, первый WarCraft на мониторах и «где вы были с мая по август» — такая строчка в биографии есть практически у всех представителей моего поколения.

Хотя некоторые конечно скрывают, до сих пор.

Так бы и закончилась эта история, не успев начаться, на одних только видеоиграх и потерянной молодости, но к счастью (или нет) в том клубе работал ночным администратором один интересный персонаж, назовем его Виталием.

А еще он умел доставать всякий разный софт.

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

Как-то раз Виталик подозвал нас к своему админскому компу и со словами «зацените пацаны что бывает на свете» запустил какую-то непонятную программу.

Все было на английском, которого никто из нас тогда не знал, по экрану бежали какие-то непонятные надписи, все мигало и переливалось.

А затем началось настоящее представление:

То что мы увидели в тот день на экране по уровню исполнения превосходило все видеоигры тех лет и даже некоторые киношные спецэффекты.

Это были времена, когда ради производительности приходилось уменьшать разрешение даже в спрайтовом Doom, а для запуска Duke Nukem был нужен как минимум первый пентиум, за который всегда была драка очередь.

А тут вращающиеся трехмерные кубы и ленты Мебиуса, на 386м!

Именно после просмотра работ демосцены поменялось мое отношение к компьютерам и программированию — я захотел делать такое же.

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

Да простят меня любители Amiga, но рассказ пойдет про период демосцены и работы, которые повлияли в первую очередь лично на автора. Никакой Амиги в пешей доступности у меня тогда не было, зато были 386/486 и первые пентиумы с DOS и Windows.

Поэтому показываю в работе это:

Windows 95, которая также стояла на клубных компьютерах тех лет не отличалась стабильностью, тормозила как могла и имела проблемы с совместимостью. Поэтому все игры и демо запускались строго под MS-DOS.

Так что именно DOS-окружение мы будем сейчас эмулировать.

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

Эмулируя ностальгию

Изначальный план был посетить с тортиком и коробкой дискет логово сектантов знаменитый «Ленинградский Компьютерный Клуб», чтобы запустить и отснять все эти замечательные демо на реальном железе тех лет, коего там в рабочем состоянии весьма немало.

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

Так что эмулируем.

86Box

И поможет нам в нелегком деле эмуляции компьютерных древностей этот замечательный проект:

86Box is a low level x86 emulator that runs older operating systems and software designed for IBM PC systems and compatibles from 1981 through fairly recent system designs based on the PCI bus.

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

Официальные релизы выкладываются на Github, где вы найдете версии для Linux, MacOS и Windows, также 86Box присутствует в виде готового пакета практически во всех дистрибутивах линукса и *BSD.

Я использовал версию 5.3 под FreeBSD:

Кстати под FreeBSD есть дурацкий прикол с именованием пакета, заставивший вначале собрать эмулятор целиком из исходников:

pkg install 86Box

Название зачем-то сделали с буквой «B» в верхнем регистре, поэтому поиском по пакетам ничего не находилось.

Но не переживайте, это единственная специфика FreeBSD, упомянутая в этой статье и все остальное, описанное ниже применимо для любой ОС, на которой работает эмулятор 86Box.

Виртуальное железо

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

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

Но ребята из 86Box пошли гораздо дальше — тут эмулируются натурально сотни разнообразных железок.

Причем при выборе неправильной комбинации оборудования, 86Box ведет себя точно также как реальный компьютер 90х:

пищит спикером, глючит и обсирается перезагружается

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

А так эмулируемые материнские платы, причем наборы разные для разных сокетов:

Но это еще не все, ниже список эмулируемых.. контроллеров дисков:

Все модели (кроме универсальных) — вполне реальные, так например выглядит в живую контроллер «Western Digital WDXT-GEN», присутствующий в списке:

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

Фактически столь богатый выбор позволяет снова поиграть в замечательную игру времен школьной молодости автора:

воткни новую железку в компьютер и посмотри что произойдет.

Только на этот раз будет без запаха сгоревшей электроники.

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

показываю полную установку MS-DOS 6.22 — той самой последней «настоящей» версии, еще не прибитой гвоздями к Windows.

На версии 7.0, включенной в состав Windows сказка закончилась и DOS из операционной системы стал превращаться в черное окно с терминалом.

Ставим MS-DOS

Разумеется давно существует куча готовых «васянских» сборок и образы загрузочных дискет с DOS самого разнообразного качества и наполнения, взять некоторые можно например отсюда.

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

Так что раздел ниже — для самых отъявленных фанатов кинематографа, остальные могут прокрутить до запуска самих демо.

Упреждая возможные вопросы на тему вареза лицензионности:

на сегодняшний день все старые версии MS-DOS официально считаются «abandonware» — заброшенным ПО, дистрибутивы которого находятся в свободном доступе.

Поэтому никаких юридических последствий от «неправомерного использования» не будет.

Автор использовал оригинальную английскую версию Microsoft MS-DOS 6.22, взяв образ дискет отсюда. Необходимо скачать три IMG-файла с образами оригинальных дискет, первый из которых является загрузочным а остальные два потребуются в процессе установки.

Подготовка виртуальной машины

Запускаем эмулятор 86Box, нажимаем большую кнопку «New Machine», задаем имя и в диалоге настройки выбираем следующую конфигурацию (первая вкладка «Machine»):

На вкладке «Video» выбираем:

Дальше, вкладка «Storage controllers»:

Затем там же ниже:

На вкладке «Hard disks» нажимаем «New» и задаем следующие параметры:

На следующей вкладке «Floppy & CD-ROM drives» переключаем тип флоппи с 360К на 1.44M и включаем устройство CD-ROM с интерфейсом ATAPI:

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

Жмем Del и попадаем в самое известное компьютерное меню на свете:

Что делать дальше думаю известно любому олдфагу, поэтому описание ниже специально для юных телезрителей:

Переходим в раздел «IDE HDD AUTO DETECTION» и нажимаем 1, затем выходим из раздела и нажимаем SAVE & EXIT SETUP»

Затем надо открыть раздел «BIOS FEATURES SETUP» и выставить значение поля «Boot Sequence» в A,C вместо С,A — для того чтобы первым для загрузки выбирался флоппи, а не жесткий диск:

Теперь при запуске должен обнаруживаться наш виртуальный диск под буквой С:

Теперь в меню «Media→Floppy 1→Existing image…» выбираем образ первой дискеты из установочного набора MS-DOS 6.22 и перезагружаем наш виртуальный PC:

Теперь при запуске должно появиться сообщение «Starting MS-DOS…»

Через какое-то время появится диалог установки, ключевые элементы которого дожили до наших дней и сохранились в современных версиях инсталлятора Windows:

Поскольку это виртуальная машина с единственным диском, думать особо не надо — просто жмете Enter, как в школьные годы.

Инсталлятор попросит перезагрузиться и если вы правильно выбрали в биосе последовательность A,C (см. выше), после перезагрузки запустится форматирование:

А еще через несколько скучных экранов наконец начнется установка:

В какой-то момент инсталлятор попросит вставить вторую а затем и третью дискеты:

После финальной перезагрузки вы наконец увидите ту самую «страшную черную консоль»:

Только на этот раз не в отдельном окне с крестиком в углу, а целиком на экране.

История с CD-ROM

Самые крутые и красивые демо внезапно оказались большими (по тогдашним меркам) и на дискету уже не влезали, что усложнило задачу их переброски внутрь работающего эмулятора с DOS.

Но поскольку 86Box поддерживает отображение каталогов хоста в виде образа виртуального CD-ROM-диска, было решено это использовать.

Для чего было оставалось сделать только самую малость:

установить драйвер CD-ROM в MS-DOS.

На самом деле для MS-DOS давно есть даже поддержка TCP/IP и можно без особых проблем вывести старушку в интернет, но размер статьи не резиновый, поэтому опишу сей интересный процесс как-нибудь в другой раз.

Скачиваем образ дискеты с драйвером (вторая ссылка сверху), подключаем в эмуляторе через меню «Media→Floppy 1»:

Переходим на диск A: где должно быть вот такое содержимое:

Запускаем SETUP.BAT (не SETUP.EXE!):

Перезагружаем систему, теперь при запуске будет происходить инициализация драйвера и добавится новый том с буквой D: , ответственной за наш виртуальный CD-ROM:

Следующим шагом в меню «Media→CD-ROM 1» выбираем «Folder…» и указываем путь к каталогу на хосте, который будет эмулироваться для MS-DOS в виде виртуального CD-ROM:

Стоит напомнить читателям про кучу ограничений файловых систем тех лет:

длина имени, кодировки, количество вложенных каталогов, размер файлов и так далее.

Так что подключаемый каталог должен содержать только то, что вы собираетесь перебрасывать в MS-DOS, не стоит подключать домашний каталог целиком или папку «Мои документы».

Кстати подключается каталог в режиме «только для чтения», поэтому записать что-либо со стороны DOS таким способом не выйдет.

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

Теперь наконец можно запускать лучшие работы из золотого фонда демосцены. Лично и своими руками.

Norton Commander

Работа в голой консоли (особенно после нового Mac) может показаться не очень комфортной, поэтому даже в те далекие годы ушлые юзеры нормальные пользователи использовали специальный файловый менеджер — Norton Commander.

Из которого затем вырастут всем известные Far Manager и Midnight Commander.

Norton Commander ныне также считается заброшенным, поэтому его дистрибутивы спокойно находятся в интернете. Классическую версию 5.5 под MS-DOS можно взять тут.

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

Теперь наконец переходим к самим демо.

Second Reality

https://www.pouet.net/prod.php?which=63

Первое место на Assembly 1993, тут запись в виде ролика.

Из отзывов:

I'd almost call it the godfather of all demo's, revolutionary for its time.

Наверное самая знаменитая работа команды Future Crew, созданная в далеком 1993 м году, которая до сих пор находится в топе демосцены всех времен.

Первые кадры заставки:

Скачиваем архив и распаковываем в ту самую папку, которую мы монтировали в эмулируемую машину как виртуальный CD-ROM.

Со стороны запущенной машины с DOS должно выглядеть как-то так:

Наконец вводим заветное SECOND.EXE и.. немедленно обламываемся:

Дело в том, что в MS-DOS существовало жесткое разделение памяти по уровням, конкретно «Conventional Memory», на которую ссылается сообщение выше это первые 640Кб.

Запускаем команду mem и видим что какая-то сволочь действительно отъела память, причем из тех самых сладких первых 640Кб:

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

Для чего надо немного поправить конфиг, конфиг для DOS да.

Вводим:

edit config.sys

Запустится знаменитый классический редактор Edit, который присутствует в операционных системах Microsoft до сих пор:

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

После перезапуска команда mem выдаст уже совершенно другую картинку, материализовав целых 619Кб свободной памяти:

Теперь наконец можно запускать SECOND.EXE:

Конечно можно выбрать «No sound», но тем самым потеряется половина удовольствия от просмотра демо.

Так что я очень советую зайти в раздел «Sound» в настройках эмулируемой машины и добавить звуковую карту:

Затем выставить карте вот такие настройки:

Чтобы вы понимали и осознали момент, вот так выглядел настоящий «гусь» — Gravis UltraSound:

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

После выбора звуковой карты наконец запустится сама демка и вы увидите лучшую для 93 года демонстрацию возможностей программистов.

Unreal

https://www.pouet.net/prod.php?which=1274

Первое место на Assembly 1992, запись в виде ролика.

Из отзывов:

This must be the first megademo I'd ever seen on the PC... runs fine on a 386 and it's got awesome gfx, killer music for its time and it's the next best thing for future crew after Second Reality. A must have.

Вторая по известности работа знаменитых сценеров Future Crew, именно ее в запущенном виде можно увидеть на заглавной картинке к статье.

Первые кадры:

Тут все просто, выбираем «Gravis Ultrasound», прозванный в народе «гусем» и жмем Enter:

Сразу после выбора звуковой карты запустится представление.

Это также одна из первых увиденных мною демок, которая будучи запущенной на 486м производила неизгладимое впечатление.

Stars: Wonders of the World

https://www.pouet.net/prod.php?which=301

Первое место на Assembly 1995, полная запись в виде ролика.

Из отзывов:

great dzgn! ra gfx, moby msx.! .. ahh.. nooon, had the power. the demo was 1st on the charts for a 2 yrs, as i rmber :)

Как видите уровень «l33t speak» зашкаливает, поскольку это работа известного сценера NooN с такими же отбитыми фанатами — они все на этом языке разговаривают ;)

Знаменитая золотая оса:

Несмотря на весьма скромные системные требования:

все же пришлось немного увеличить общий размер памяти — до 8Мб, чтобы не выгружать резидентов:

Дальше запускаем STARS.EXE и наслаждаемся шоу.

Думаю уже на первой минуте просмотра станет понятно почему и за что работе выдали первое место.

Inside

https://www.pouet.net/prod.php?which=74

Первое место на The Gathering 1996, полная запись в виде ролика.

Из отзывов:

how to define "cool"? well, this monster is really a "cool" demo! even shaft would be proud of it.

Еще одна классическая работа сценеров из группы CNCD, оставивших заметный след в виде огромного количества работ, начиная еще с Amiga.

Первые кадры:

Это демо требует более мощного железа и на 486м запускаться отказывается:

Поэтому либо создаем новую виртуальную машину в эмуляторе, либо меняем настройку у существующей, произведя таким образом «апгрейд»:

Еще надо обновить звуковую карту, поскольку с «гусем» демо также работать отказывается.

Выбираем «Sound Blaster 16» и выставляем настройки:

В обоих случаях повторять установку MS-DOS с нуля не надо, достаточно подключить созданный в прошлый раз образ диска.

Кстати примерно такой же апгрейд когда-то произошел и в реальности:

автор будучи школьником обновлял свой 486й на первый пентимум.

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

Но вернемся к демке.

С «Inside» есть еще одна существенная проблема:

тут есть отдельный конфигуратор для звуковой карты, который пишет настройку на диск.

А поскольку мы все это время запускали демки с виртуального CD-ROM — ничего сохранить конфигуратор не сможет, придется копировать каталог с демо на диск С: и запускать уже оттуда.

Также стоит удалить файл SOUND.CFG, который присутствует в оригинальном архиве с демо — на нем зачем-то поставили атрибут «только для чтения», отчего конфигуратор не может этот файл перезаписать.

Запускаем SETUP.EXE (тот самый конфигуратор) и выбираем из списка «Sound Blaster 16 driver»:

Дальше просто последовательно жмем Enter, в конце должно появиться сообщение, что конфигурация успешно сохранена:

Теперь наконец можно запускать, вводим INSIDE.EXE и наслаждаемся шедевром из 1996 года.

Contrast

https://www.pouet.net/prod.php?which=72

Первое место на Saturne 1996, полная запись в виде ролика.

Из комментариев:

This demo along with Bomb/Impact Studios, changed single-handedly the PC demoscene. It was in France, same year, same party, both prods. None is better than the other, yet they are both very relevand. Constrast is an instant classic. It's worth paying attention to this production.

Да это тоже классика демосцены, работа именитой французской команды Oxygene [OXG], которая недавно отметила юбилей — 30 лет!

Не все так долго на свете живут, сколько эти парни присутствуют на сцене.

Первые кадры:

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

Запускаем CONTRAST.EXE, появится меню выбора звуковой карты, где выбираем «Sound Blaster 16»:

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

Не забывайте утирать слезы восторга при просмотре, поскольку на 1996й год сопоставимая графика была лишь в Голливуде.

Сцена мертва?

Существует распространенное мнение, что «демосцена мертва», «ее лучшие годы давно прошли» и новых эпических работ больше не будет.

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

Area 5150 by CRTC & Hornet

https://www.pouet.net/prod.php?which=91938

Работа 2022(!) года, занявшая первое место на Evoke 2022 и очень быстро вставшая на один уровень с золотой классикой демосцены, рядом с «Second Reality» и «Crystal Dream 2»:

Только вдумайтесь в эти требования:

IBM PC, CGA, 4.77 MHz 8088, hard drive

Все это — невероятный винтаж, железо из 1981 года (старше автора), CGA-монитор с 16 цветами выглядел как-то так:

И вот на таком музейном экспонате авторы умудрились закодировать это, причем относительно недавно — в 2022м году:

Из отзывов:

crazy good! lot of content with surreal quality for the platform limitations
wow!! incredible
(Did...did someone already dare to tell them there's EGA nowadays?)
Jesus Bitshifting Christ, this isn't even funny anymore.
Fantastic!!! You have done the impossible!

Cамый частый вопрос к создателям (помимо обвинений в колдовстве), судя по отзывам, был «как такое вообще возможно».

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

Теперь о плохом и печальном:

чтобы запустить демо, придется серьезно напрячься — эмулировать PC XT и запустить внутри MS-DOS 3.20.

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

Собираем виртуальную машину со следующими настройками:

На этот раз никаких CD-ROM и контроллеров дисков, только флоппи, только хардкор:

Не забываем выставить тип монитора как CGA:

Включаем оба дисковода, первый оставляем с форматом 360к — с него будет загружаться MS-DOS, у второго выставляем формат 720к:

720к нужен по той простой причине, что демо довольно жирное и на 360к не помещается.

А более современный 1.44M старый MS-DOS еще не поддерживал — в качестве исторической справки.

Образ MS-DOS 3.20 можно скачать тут, автор использовал версию для компьютеров Olivetti, про которые тоже стоит как-нибудь рассказать.

Следующий головоломный этап — пробросить демо на эмулируемый компьютер 1981 года.

С этой задачей поможет пакет GNU Mtools, про который уже как-то рассказывал. Пакет весьма известный, поэтому скорее всего будет доступен и в вашей системе под одним и тем же названием mtools.

Скачиваем архив с демо и распаковываем, затем создаем новый пустой образ дискеты на 720Кб:

mformat -f 720 -C -i ./floppy.img

Копируем внутрь образа все файлы демки (их довольно много):

mcopy -i floppy.img ./area/* ::

Дальше запускаем виртуальный PC XT и с помощью меню «Media» вставляем в первый дисковод загрузочный образ MS-DOS 3.20, а во второй — только что созданный образ с демо:

Переходим на диск B: и наконец запускаем этот шедевр:

Дабы избежать ненужного негатива, сразу предупреждаю, что некоторые эффекты работают в эмуляторе 86Box неправильно:

Sorry we broke all your emulators again!

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

Чтобы в полной мере насладиться этой уникальной работой, стоит использовать более специализированный эмулятор MartyPC, специально созданный для максимально точной эмуляции компьютера PC XT.

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

Спонсоры

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

Так что историю с рассказами о демосцене точно будем продолжать.

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

«Карпати, один из самых влиятельных людей в мире AI, собрал второй мозг на LLM. А ты до сих пор какой-то фигней занимаешься» — из отзывов.

Осенью 2012 года, устав гонять разработчиков за обмен корпоративными исходниками через публичный Pastebin, решил сделать его аналог, для внутреннего использования.

Так появился проект «Пастер», существующий до сих пор.

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

Идея

Как уже было упомянуто выше, главной идеей проекта была легковесная, развертываемая локально замена известному сервису Pastebin:

Затем генерируется ссылка для просмотра, которая отправляется через мессенжеры всем заинтересованным лицам. Через какое-то время устаревшие записи удаляются.

Все просто.

Позже появилась подсветка синтаксиса, построчные комментарии, авторизация и даже возможность что-то нарисовать поверх текста, но самое главное что оставалось неизменным — функциональная замена Pastebin.

Про текущий функционал Пастера есть отдельная статья с картинками, ныне это выглядит как-то так:

Проектов, реализующих подобную идею в том или ином виде — как говна за баней очень много.

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

Но как обычно есть нюанс:

как брак не заканчивается на свадьбе, так и программный проект не заканчивается на разработке.

В обоих случаях самое интересное происходит за закрытыми дверями на длинной дистанции.

Особенности реализации

Стоит сразу сказать, что «Пастер» никогда не был коммерческим проектом и всю свою 14 летнюю историю представлял из себя внутренний инструмент, разрабатываемый в свободное время и с чисто прикладными задачами.

Поэтому технологии для реализации проекта выбирались из того что было под рукой (например знаменитый в те годы Appfuse — предок JHipster) или из тех технологий, что были интересны автору.

Это кстати характерный штрих, поскольку именно из таких опций (интерес и наличие под рукой) чаще всего происходит выбор технологического стека на практике. Все эти ваши «оптимально для выбранной задачи», «применимость» или «успешные кейсы» остаются обычно на уровне презентации.

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

Были попытки обойтись и без СУБД, но довольно быстро выяснилось, что сопровождать на длинной дистанции физическое хранение и процесс записи на диск в рамках прикладного проекта слишком накладно. Хотя начальная разработка безусловно была проста и красива.

Не взлетела и реализация с хранением записей только в памяти — все закончилось на первом же обновлении:

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

Даже если записи считаются временными.

Примерно по той же причине сильной недооценки важности пользовательских данных отказались и от нереляционных СУБД и от попыток хранения записей в файлах и поисковых индексах.

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

Репозиторий

Практически все время — все 14 лет разработка Пастера велась в одном и том же публичном репозитории на Github.

Но ввиду загруженности по основным проектам — далеко не всегда получалось создавать нормальные коммиты с описанием функционала, так что треша внутри хватает.

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

Ниже будут примеры исходного кода как из текущей, так и из старых версий Пастера, хотя все они находятся в одном и том же репозитории.

Выбор Scala

Хотя Scala на 2012й год была весьма стабильной и для Пастера использовалась уже 2.х версия языка — связку Scala + Spring + Hibernate, где существенная часть логики связана с обработкой аннотаций на клиентских классах, на практике мало кто использовал.

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

Для примера, далеко не сразу выяснилось, что у полей Entity класса, реализованного на Scala должно быть значение по-умолчанию:

@ManyToOne(fetch = FetchType.EAGER,cascade= Array(CascadeType.PERSIST,CascadeType.MERGE))
@JoinColumn(name = "owner_id")
private var owner:User = null

Были проблемы с типами данных, с наследованием классов, с перечислениями (enum), с аннотациями — удалось собрать наверное все возможные проблемы совместимости Java и Scala с точки зрения прикладного проекта.

Кстати на момент создания Пастера, существовала только одна реализация Scala — на базе JVM и компиляцией в байткод, компиляторы в JavaScript (Scala.js) и нативный код появились позже.

Так что технически Пастер работал и работает на обычной JVM, хотя его исходный код (бекэнд) написан на Scala.

История с Maven

Традиционной для проектов на Scala системой сборки считается sbt — такая своеобразная штука, больше всего похожая на Gradle, но использующая «Scala-based DSL» вместо Groovy в качестве языка сценариев.

На момент создания Пастера, sbt был еще очень сырым проектом и что куда важнее — очень плохо интегрировался со средами разработки.

Это сейчас проект на sbt легко подхватывается и на CI-сервере и в любой современной IDE, но в 2012м все было сильно хуже.

Вторым важным нюансом, повлиявшим на выбор была сложность сборки.

Даже в первой версии Пастера, выложенной на Github можно можно увидеть интеграцию с системой контроля качества кода SonarCube, генерацию номера сборки, поддержки нескольких разных СУБД и двух сервлет-контейнеров.

Повторить все это на sbt было откровенно непростой задачей.

Впрочем о выборе стандартного Maven в качестве средства сборки ни разу за 14 лет пожалеть не пришлось, благо этот проект удивительно стабилен и предсказуем.

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

Падение Compass Search

Проект «Compass Search» был далеким предком современного и известного ElasticSearch от того же автора:

The Compass Framework enables the power of Search Engine semantics to your application stack declaratively. Built on top of the amazing Lucene Search Engine, Compass integrates seamlessly to popular development frameworks like Hibernate and Spring.

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

Тут можно посмотреть сохраненную копию документации, тут находится неофициальный форк исходников Compass Search, судя по датам созданный еще при жизни проекта.

Меньше, проще и с более интересным функционалом, чем у известного Hibernate Search, Compass казался отличным вариантом в качестве встраиваемого поискового движка для нашего Пастера.

Только мы не подозревали, что автор этого замечательного фреймворка давно все решил:

Developing a third version of Compass, he concluded that a full rewrite was necessary to build a scalable, distributed search solution using JSON over HTTP as a common interface.[3]

Несмотря на дату сохраненного поста (2010 год), проект Elasticsearch еще довольно долго не был известен широкой публике, а сам автор не отказывался от поддержки «Compass Search».

Вот так просто и на ровном месте мы оказались с мертвым фреймворком внутри нашего проекта, от которого зависел ключевой функционал поиска. 

С большой (по меркам прикладного проекта) и теперь уже мертвой кодовой базой, которая начинала быстро портиться.

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

Поддерживать самостоятельно кодовую базу умершего Compass Search становилось все труднее.

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

Но это был далеко не конец.

Падение Apache Tiles

К сожалению описанные выше проблемы и беды с Compass Search были далеко не единственными. В Пастере использовался еще один интересный фреймворк, также успевший помереть за время жизни проекта:

A free open-sourced templating framework for modern Java applications.
Based upon the Composite pattern it is built to simplify the development of user interfaces. For complex web sites it remains the easiest and most elegant way to work alongside any MVC technology.

Тут стоит пояснить подрастающему поколению, видевшему серверный шаблонизатор страниц только в виде SSR, что Apache Tiles добавлял один ключевой функционал, которого по какой-то причине не было в технологии Java Server Pages (JSP) — вложенность.

Так это работало и работает во всех популярных фреймворках, включая ваши любимые Angular, Vue и React. И только в JSP решили, что будет достаточно лишь явно включать отдельные части.

Поэтому любая страница на чистом JSP выглядит примерно так:

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<!DOCTYPE html>
<html>
<head>
   <!-- кусок HTML с заголовком -->
   <c:import url="header.jsp" />
</head>
<body>
  <!-- содержимое страницы -->
   <%@include file="body.jsp"%>
</body>
<footer>
   <!-- кусок HTML с футером -->
   <jsp:include page="footer.jsp" />
</footer>
</html>

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

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

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

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

<definition name=".mainTemplate" 
      template="/WEB-INF/pages/template/main.jsp" 
      preparer="uber.paste.tiles2.ELViewPreparer">
    <put-attribute name="pageTitle"  expression="${requestScope.title}" />
    <put-attribute name="menu" value="/WEB-INF/pages/template/menu.jsp" />
    <put-attribute name="content" value="" />                
</definition>

А затем сами страницы, использующие этот шаблон:

<definition name="/paste/list" extends=".mainTemplate">
      <put-attribute name="content" value="/WEB-INF/pages/paste/list.jsp" />
</definition>

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

С учетом поддержки прекомпиляции JSP-страниц, решение было еще и весьма производительным — фактически самые быстрые страницы на Диком Западе.

Точно быстрее любой реализации JSF и тем более чистых парсеров вроде Velocity или Freemarker.

И все были счастливы и довольны, пока не закачался трон под самим JSP — случилась «утрата интереса к технологии» (отчасти искусственная, организованная ради перехода на JSF), с чего будущее проекта Apache Tiles внезапно стало туманным.

Что характерно, обе технологии нижнего уровня — JSP и JSF продолжают развиваться и все также остаются частью стандарта JakartaEE, но зависимый от них «Apache Tiles» зиму не пережил.

С «Apache Tiles» случилась еще одна беда, предсказуемо последовавшая за заморозкой проекта — из Spring выкинули его интеграцию.

Причем случилось это на весьма небольшом временном отрезке — всего за пару лет жизни Пастера.

Удаление интеграции означало невозможность дальнейшего использования Apache Tiles в проекте, начиная с определенной версии Spring.

А дыры в безопасности при всем этом никто не отменял — оставлять устаревшие версии Spring ныне не дает даже Github, задалбывая уведомлениями о «страшных ошибках в безопасности».

На этот раз, ввиду небольшого объема «Apache Tiles» было принято решение его форкнуть и поддерживать своими силами:

благодаря мощному движку для рефакторинга в Intellij Idea удалось выкинуть из Apache Tiles все лишнее, заодно портировав на современную Jakarta.

Слой интеграции со Spring MVC был переписан целиком на Scala.

Разумеется это отняло много времени и сил, но других разумных вариантов попросту не нашлось.

Например переезд на стандартный для современного Spring Boot фреймворк Thymeleaf означал бы полное переписывание всех JSP-страниц с нуля. Плюс падение производительности, поскольку Thymeleaf заметно медленнее JSP.

Но это еще не все несчастья, собранные Пастером за годы жизни.

Падение Mootools

Mootools когда-то был вторым по популярности веб-фреймворком после jQuery в мире веб-разработки:

MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer.
It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.

Он был заметно легче jQuery, поэтому был популярен среди продвинутых веб-разработчиков, особенно отечественных.

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

По какой-то причине GitHub не смог адекватно распознать используемые технологии, поэтому в плашке проекта до сих пор висит только JavaScript:

Когда мы показывали Пастер потенциальному заказчику в качестве примера проекта на Scala — тот подумал, что мы его обманываем, пытаясь подсунуть какую-то хрень на Node.js.

Но вернемся к истории с Mootools.

Хотя к тому времени появилась первая версия знаменитого Angular (тогда еще AngularJS), вызвавшая немалый интерес у веб-разработчиков, столь резкого падения проекта Mootools не ожидал никто. 

Тем более что его аналог — jQuery жив и развивается до сих пор.

Mootools активно использовался в популярных движках CMS, CRM, блогов, в открытых и коммерческих проектах.

Можно разумеется пытаться искать причины и подбирать тайные смыслы, но повторюсь:

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

В итоге получилось, что примерно 40% кодовой базы проекта (практически весь фронтэнд) напрямую зависела от ключевого JavaScript-фреймворка, который приказал долго жить.

Попробовав разные варианты, вдоволь наигравшись с разными версиями Angular и их замечательной совместимостью, к 2020му году пришли к выводу, что нах#й их всех стоит полностью отвязаться от больших фреймворков и переделать фронтэнд на чистый ES6.

Благо его поддержка (пусть и не полная) к тому времени появилась во всех основных браузерах и работала уже без транспилеров.

Часть библиотек, зависимых от Mootools, например LazyPagination была переписана на чистый ES6, часть заменена на аналоги, работающие на чистом JavaScript, часть просто выкинута.

Вот так постепенно, маленькими шажками удалось избавиться от Mootools, хотя на весь процесс ушел год.

Спросите, почему не взяли Angular/React/Vue ?

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

Только вам об этом конечно никто не расскажет.

Падение SyntaxHighlighter

Жил-был на свете (в солнечной Калифорнии) отличный разработчик Alex Gorbatchev, создавший в 2004м году уникальную и очень популярную библиотеку для подсветки синтаксиса, которая так и называлась «Syntax Highlighter».

Написано все было на чистом JavaScript и без внешних зависимостей а уникальна библиотека в первую очередь своей производительностью:

Не каждый нативный редактор с таким справляется в 2026м году, а тут какая-то библиотека на JavaScript.

К сожалению со временем автор потерял интерес к собственному детищу и к 2016 году разработка проекта «Syntax Highlighter» была прекращена.

Вот тут находятся исходники последней релизной 3.х версии. Четвертую, которая находится в том же репозитории автор так и не выпустил.

Что характерно, история «Syntax Highlighter» закончилась на попытке переписать на Typescript. Совпадение?

Да, мы тоже использовали эту замечательную библиотеку в Пастере.

Однако практически сразу нам пришлось добавлять в «Syntax Highligher» дополнительную логику для поддержки построчных комментариев, так что факт смерти родительского проекта нас не особо затронул — в проекте давно использовался собственный форк.

Со временем форкнутый исходный код подвергся изменениям:

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

Хотя конечно с точки зрения проектного управления и ресурсных трат это был полный провал:

В коммерческом проекте я бы такое делать не стал.

Ужасы Jetty и Spring Boot

На момент начала работы над Пастером, концепция «пихаем все в один большой запускаемый JAR» еще не была массовой.

Конечно с таким подходом активно экспериментировали, например в знаменитом Jenkins CI, но стандартом пока еще оставалось развертывание в сервлет-контейнере или на сервере приложений, задача настройки которых была на совести сисадмина, но не разработчика.

Spring Boot появится только в 2014м и на фоне возрастающего интереса к микросервисам, быстро приучит Java-разработчиков к тому, что пихать целиком сервлет-контейнер в каждое отдельное приложение это нормально.

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

Первые установки Пастера были в обычном Apache Tomcat или Eclipse Jetty, а само приложение поставлялось в виде WAR-файла, который надо было закидывать в специальный каталог.

Так что вся цепочка была слишком сложной для столь простого проекта:

• Установка JDK (обычные JSP-страницы на JRE не работали);
• Установка сервлет-контейнера Tomcat или Jetty;
• Копирование приложения Пастера в специальный каталог webapps;
• Запуск сервлет-контейнера.

Добавьте сюда особенности настройки сервлет-контейнеров и проблемы совместимости между Tomcat/Jetty разных версий — поймете, что сил на такую поддержку уходило просто немеряно.

Со временем изменилось и внешнее окружение:

все чаще приходилось запускать Пастер в каком-нибудь контейнере Docker и дополнительный слой в виде сервлет-контейнера, требующего отдельной настройки стал откровенно раздражать.

Требовалось серьезное упрощение.

Конечно мы экспериментировали и со Spring Boot, тем более что параллельно шли коммерческие проекты с его использованием.

Но оказалось, что поддержка JSP в случае приложения на Spring Boot откровенно хромает и чинить ее никто особо не собирается:

команда Spring активно продвигала Thymeleaf как полную замену «устаревшему» JSP, хотя тот был и остается частью спецификации JEE/JakartaEE, а Thymeleaf — непонятная приблуда, ни с чем не совместимая.

С точки зрения Spring все было разумеется прекрасно, поскольку Thymeleaf идеально вписывался в экосистему фреймворка и был полностью подконтролен.

Собственно развитие Thymeleaf до сих пор происходит под чутким руководством ребят из Spring и каким-то удивительным образом используется Thymeleaf по большей части только в составе Spring.

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

отголоски всех этих разборок с упаковкой приложения можно обнаружить например в знаменитой Atlassian Jira, в ее self-hosted версии.

Вообще на свете до сих пор существует довольно много разных CMS/CRM/ERP систем и портальных движков, чья разработка началась еще в начале 2000х и где присутствует эта проблема с развертыванием.

Мы же дети советских инженеров решили пойти особым путем — попытаться забороть проблему загрузки JSP и сканирования TLD-файлов без распаковки WAR.

Долго и внимательно изучая механизм загрузки классов в Jetty и «черную магию» Spring Boot с многоступенчатой загрузкой классов, удалось-таки создать работающее решение.

Ушло всего-то пару лет.

Зато теперь мы полностью контролируем весь процесс запуска, при этом сам Пастер все также остается стандартным сервлет-приложением и легко может быть развернут в обычном Apache Tomcat.

Мертвые фичи

За годы работы Пастера, добавлялись и удалялись самые разные фичи, часто уводившие проект сильно далеко от основной задачи.

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

Отображение в офисные форматы

В Spring MVC еще с тех лет, когда разработка Пастера только начиналась существует интересный функционал, позволяющий выдавать из слоя View (V — в аббревиатуре MVC) не только стандартные HTML, XML или JSON, но и другие форматы данных: PDF, DOCX, XLS и так далее.

С его помощью были реализованы генераторы в docx для записей и в xlsx для списков и поиска — да, можно было получить результат поиска и фильтрации сразу в виде документа Microsoft Excel.

Почему не взлетело:

простой текст, вставленный в подготовленный шаблон документа Microsoft Word оказался мало актуальным а полноценное превращение текста в документ — с абзацами и форматированием требовало слишком больших ресурсов.

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

Но фича красивая да.

Интеграция с почтой

Пользователи присылают вопросы, жалобы и предложения на почту, специальный адаптер их выгребает и загружает в Пастер.

Получается альтернативный сценарий использования.

Почему не взлетело:

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

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

Итеграция со Skype

С помощью неофициального API, имитирующего веб-клиент, были реализованы оповещения о новых записях Пастера в Skype — некий аналог современного Телеграм-бота.

Почему не взлетело:

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

К тому же к 2018 году пришел Телеграм, в который очень бысто перетекла вся переписка, а сам скайп стал постепенно умирать.

Телеграм принес с собой новую культуру отказа от раздражителей и теперь любые оповещения стали восприниматься как отвлекающий фактор.

Поэтому на сегодня мы от них полностью отказались.

Авторизация через социальные сети

Когда-то в Spring был дочерний проект, посвященный авторизации через социальные сети:

The Spring Social project enables your applications to establish Connections with Software-as-a-Service (SaaS) Providers such as Facebook and Twitter to invoke APIs on behalf of Users.

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

Мы использовали Spring Social в Пастере для авторизации через социальные сети: Google, VK, LinkedIn и это даже работало, включая связывание разных профилей.

Почему не взлетело:

Использование Spring Social было частью концепции облачного использования Пастера для публичных проектов — хотели сделать что-то типа Github в плане коллаборации.

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

Смерть проекта Spring Social окончательно похоронила эту идею и возвращаться к ней в современных реалиях откровенно бессмысленно.

Интеграция с Jira

Одна из самых долгоживущих интеграций была с знаменитым багтрекером Atlassian Jira.

Специальный плагин, устанавливаемый в Jira подтягивал на странице детализации записи из Пастера, связанные с просматриваемой задачей.

Таким образом сам трекер не захламлялся кусками логов и трассировками ошибок.

Почему не взлетело:

Проектов, использующих Jira становилось все меньше, а там где она еще использовалась — нам не давали доступ для установки плагина.

Нашим внутренним трекером постепенно стал Redmine, так что интеграция потеряла всякую актуальность.

Интеграция с файловым хранилищем

Помимо обмена кусками кода через публичные сервисы, с разработчиками была еще одна проблема — постоянное перекидывание файлов через публичные сервисы.

Народ запросто выкладывал фактически в публичный доступ бинарные сборки, скрипты, библиотеки, логи и конфиги.

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

Поскольку оба проекта работали одновременно, логично было их интегрировать. Что в итоге и произошло:

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

Со стороны хранилища работала версионность, поэтому можно было легко отслеживать изменения.

Почему не взлетело:

со временем концепция обмена файлами при командной разработке поменялась и мы в итоге пришли к Телепорте

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

Исходники этого проекта находятся в одном репозитории с Пастером и все еще доступны в старых версиях.

Туманное будущее

На момент написания этой статьи готовится новый релиз Пастера — с переездом на Jakarta 11, обновлением всех используемых библиотек и мелким рефакторингом.

Немедленно выяснилось, что в Spring 7 решили полностью отказаться от логики «Content Negotiation» — переключение типа выдаваемых данных в зависимости от расширения файла (одна из ключевых фишек Пастера) будет полностью похоронено.

Никакаких альтернатив разработчиками Spring предложено не было и что теперь с этим делать не очень понятно.

Одновременно с этим разработчики Scala грозятся похоронить 2.х ветку и начать переводить всех в принудительном порядке на Scala3 — фактически другой язык.

Конечно же без альтернативных вариантов.

Эпилог

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

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

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

Зато думаю теперь вы понимаете, зачем большие компании сами собирают весь свой инструментарий из исходников, почему у Google есть свои компиляторы, а у Яндекса — свои ключевые фреймворки.

~120 строк на Python.

Задача

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

Ну и конечно отображение температуры с датчиков персонального компьютера давным давно реализовано и присутствует в виде виджета во всех основных графических окружениях и для любых ОС.

Чаще всего это выглядит как-то так:

Это все к вопросу об уникальности, важности и полезности решения, как бы заранее отвечая на самый важный вопрос бытия: «нах#я я все это читаю».

Кстати одна из первых разработанных автором систем была как раз на тему мониторинга температуры у парка серверов.

Дело было давно и сервера (как и сетевое оборудование) стояли не в охлаждаемых и чистых серверных, а где придется.

С соответствующими последствиями по перегреву.

Выглядело оно как-то так:

Так выглядит виновник сегодняшнего торжества:

Исходный код можно посмотреть чуть ниже в статье или вот тут в виде gist. Теперь рассказываю подробнее как оно все работает.

Кстати думаю для многих станет сюрпризом, что X-сервер позволяет рисовать графические элементы и текст в чужих окнах.

Без предупреждения, без индикации, без каких-то отдельных прав и тд.

Очко сотрудников СБ только что заиграло новыми красками.

Реализация

Поскольку у автора используется тот еще зоопарк разных систем, хотелось сделать максимально переносимое решение.

Хардкодить все на чистом С я посчитал излишним, поэтому был взят Python и библиотека Xlib, которая есть везде, куда еще не добрались проклятые зумеры со своим Wayland.

К моему великому сожалению, оказалось что знаменитая связка Tcl/Tk не умеет работать с root window, поэтому использовать их не получится.

Именно поэтому был взят петон, да.

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

pkg install py311-python-xlib

Аналогичные пакеты есть в любом линуксе и BSD. Теперь стоит рассказать про сами датчики.

Датчики температуры в случае FreeBSD отдают свои значения через sysctl и требуют подгрузки специального модуля ядра.

Чаще всего это будет coretemp:

kldload coretemp

Чтение значений датчиков будет выглядеть как-то так:

Для процессоров AMD есть отдельный модуль amdtemp:

kldload amdtemp

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

sysctl dev.amdtemp.0 |grep core

В случае линукса температуру с датчиков можно получить из специальной виртуальной файловой системы /dev:

cat /sys/class/thermal/thermal_zone*/temp

Так это выглядит в работе:

Исходный код

Ниже представлен полный исходный код моей утилиты, технически это shebang — самозапускаемый скрипт на Python, поэтому его нужно сохранить с расширением .sh и поставить бит запуска.

Собственно код:

#!/usr/bin/env python3

import Xlib
from Xlib import display, X   # display и X - не импортируются автоматически
import subprocess,time,logging

#настройки логирования
logging.basicConfig(level=logging.INFO)
#logging.basicConfig(level=logging.DEBUG)

# координаты на экране для отображения
POS_X = 150
POS_Y = 50
# для FreeBSD и машины с AMD
PATTERN = 'sysctl dev.amdtemp.0 |grep core'
# для FreeBSD с модулем coretemp
#PATTERN = 'sysctl dev.cpu |grep temperature'
# для Linux
#PATTERN = "cat /sys/class/thermal/thermal_zone*/temp | awk '{ print \"temp: \" ($1 / 1000) \"C\" }'"
# шрифт
FONT = '-misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1'
# период обновления
REFRESH_SECS = 15

last_dim = [0,0]

# определение рабочего стола
# d - display (экран)s
def get_root_window(d):
    
    screen = d.screen()
    # root window - рабочий стол по-умолчанию
    root = screen.root

    # Получаем ID всех окон верхнего уровня
    windowIDs = root.get_full_property(d.intern_atom('_NET_CLIENT_LIST'), 
                                                  X.AnyPropertyType).value
    logging.debug('Found %d windows.',len(windowIDs))

    for windowID in windowIDs:
        # Create a window object from the ID to access its properties
        window = d.create_resource_object('window', windowID)

        try:
            # Get the window title (WM_NAME or _NET_WM_NAME)
            # Use get_wm_name() for simplicity, 
            # or look up EWMH properties for better compatibility
            window_name = window.get_wm_name()
            if window_name:
                # в продвинутых DE вроде KDE/Xfce за рабочий стол отвечает
                # отдельное окно и рисовать придется в нем
                if 'Desktop' in window_name:
                    logging.debug("Found desktop ID: %d - Name: %s",
                                                 windowID,window_name)
                    return window
            else:
                # Бывает, что у окна нет заголовка
                logging.debug("ID: %d - Name: None (no WM_NAME property)",
                                                 windowID)

        except X.BadWindow:
            # Обработка ситуации, когда считываемое окно больше не существует
            logging.debug("ID: %d - Window no longer exists",windowID)
    # если отдельного окна с именем Desktop не обнаружено - рисуем
    # прямо на root window 
    return root

# очистка области
def clear_rect(msg):
    global last_dim
    # если есть сохраненные размеры - используем их
    if last_dim[0] > 0:	
    	root.fill_rectangle(gc2, POS_X,POS_Y-last_dim[1], 
    	                         last_dim[0]-20, last_dim[1]+5)
    else:
        # расчет размеров надписи в пикселях
        text_extents = font.query_text_extents(msg)
        tw = text_extents.overall_width
        th = text_extents.font_ascent + text_extents.font_descent
        # очистка происходит через отрисовку черного прямоугольника
        # clear_area плохо работает с KDE
        root.fill_rectangle(gc2, POS_X,POS_Y-th, tw-20, th+5)
        # запоминаем размеры надписи для следующей очистки
        last_dim = [tw,th]

# отрисовка сообщения на экране
# msg - текст сообщения
def draw_message(msg):
    # очистка области
    clear_rect(msg)
    # отрисовка текста
    root.draw_text(gc, POS_X, POS_Y, msg)
    display.flush()

# инициализация подключения к Х-серверу
display = Xlib.display.Display()
screen = display.screen()
root = get_root_window(display)

# Access the window ID (an integer)
root_id = root.id

logging.debug("Root window ID: %d",root_id)
# для реакции на события
root.change_attributes(event_mask=X.ExposureMask)  # "adds" this event mask
# создание графического контекста, белый текст на черном фоне
gc = root.create_gc(foreground = screen.white_pixel, 
                    background = screen.black_pixel)
# дополнительный контекст для заливки области черным
colormap = screen.default_colormap
color = colormap.alloc_named_color('black') 
gc2 = root.create_gc(foreground=color.pixel)

# загружаем шрифт, которым будет отрисовываться текст
# если шрифт с таким названием не будет найден - вылетит ошибка
try:
    font = display.open_font(FONT)
    gc.font = font.id
except Exception as e:
    logging.exception(e)
    exit(1)

try:
    # бесконечный цикл, в котором происходит все действо
    while 1:
            # запуск процесса для получения значений датчиков
            process = subprocess.Popen(PATTERN, 
                    shell=True, text=True,
                    stdout=subprocess.PIPE)
            # в этой переменной будет массив строк со значениями   
            stdout_list = process.communicate()[0].split('\n')

            out = ''
            # делаем чистку
            for s in stdout_list:
                # убираем ошибочные строки, если нет : - нет и значения
                if ':' not in s: continue
                kv = s.split(':')
                # добавляем запятую в качестве разделителя 
                if len(out) > 0: out+= ','
                # добавляем значение датчика в строку
                out+= kv[1]

            logging.debug(out)
            # отрисовываем полученную строку
            draw_message(out.encode())
            # задержка между итерациями
            time.sleep(REFRESH_SECS)
            
except KeyboardInterrupt:
        # при нажатии Ctrl-C делаем очистку области экрана, где
        # происходила отрисовка виджета
        x = POS_X // 2
        y = POS_Y // 2
        root.clear_area(x,y,last_dim[0]+x,last_dim[1]+y,True)
        display.flush()

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

Настройка логирования:

logging.basicConfig(level=logging.INFO)
#logging.basicConfig(level=logging.DEBUG)

Координаты для отображения на экране (левый нижний угол):

POS_X = 150
POS_Y = 50

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

# для FreeBSD и машины с AMD
PATTERN = 'sysctl dev.amdtemp.0 |grep core'
# для FreeBSD с модулем coretemp
PATTERN = 'sysctl dev.cpu |grep temperature'
# для Linux
PATTERN = "cat /sys/class/thermal/thermal_zone*/temp | awk '{ print \"temp: \" ($1 / 1000) \"C\" }'"

Шрифт, которым будут отображаться значения температуры, указывается в специальном формате:

FONT = '-misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1'

Частота обновлений в секундах:

REFRESH_SECS = 15

Так виджет выглядит на Ubuntu и Xfce:

В помощь начинающему, продолжающему и заканчивающему автору.

Очко электрона

Следующим по уровню безнадежности занятием на FreeBSD, после нейросетей и разработки на .NET является работа с приложениями на Electron.

Широкие народные массы требуют это и уже очень давно:

Но ввиду разных причин (в первую очередь идеологических), официальной поддержки все также нет.

И скорее всего не будет никогда.

Форк очень даже живой:

Как можно заметить из истории коммитов выше — идет активная разработка и прием пул-реквестов.

Но как обычно есть нюанс:

Но портировали на FreeBSD только движок Electron, без средств сборки конечных приложений на нем.

Речь в первую очередь про electron-builder:

A complete solution to package and build a ready for distribution Electron, Proton Native app for macOS, Windows and Linux with “auto update” support out of the box.

Это не означает, что приложение на Electron не будет работать на FreeBSD совсем, но и не значит, что полноценная разработка таких приложений там возможна.

Немного работает — так это обычно описывают.

MarkText

MarkText это такой редактор для Markdown-разметки, один из самых лучших, известных и популярных:

A simple and elegant open-source markdown editor that focused on speed and usability.

Именно его я использую для верстки своих статей и документации.

К сожалению редактор построен на том самом Electron, поэтому для нормальных людей, не отягощенных двумя десятилетиями разработки нет вариантов его использования на FreeBSD — ни в Wine, ни с помощью слоя совместимости с Linux эта штука не работает.

Хотя пожелания есть:

Скотская сборка

Как бы это ни было удивительно, но Node.js и npm давно и успешно работают во FreeBSD, поэтому все спокойно устанавливается из пакетов:

pkg install node25 electron37 npm-node25 

Забираем исходники редактора:

git clone --depth 1 https://github.com/marktext/marktext.git

Активная разработка по какой-то причине остановлена, народ начинает беспокоиться, поэтому я не стал заморачиваться релизными версиями и собирал из текущей ветки.

Сборка использует еще один пакетный менеджер — yarn, который необходимо установить с помощью npm:

npm -g i yarn

Дальше начинается первый нюанс:

необходимо отключить скачивание бинарной сборки Electron, поскольку ее не существует для FreeBSD.

Перед запуском скачивания зависимостей, необходимо выставить специальную переменную:

export ELECTRON_SKIP_BINARY_DOWNLOAD=1 
yarn install

Через какое-то время (скачивание зависимостей в проекте на Node.js — очень долгий и болезненный процесс) в корневом каталоге должна появиться папка node_modules откровенно скотских размеров:

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

В файле src/main/index.jsесть вот такой замечательный код:

// NOTE: We only support Linux, macOS and Windows but not BSD nor SunOS.
if (!/^(darwin|win32|linux)$/i.test(process.platform)) {
  process.stdout.write(`Operating system "${process.platform}" is not supported! Please open an issue at "https://github.com/marktext/marktext".\n`)
  process.exit(1)
}

Не представляю кто смог упороться до такой степени, чтобы гонять десктоп-приложение на Electron на Солярисе, но думаю не будет откровением, что вызов process.exit(1) необходимо закомментировать для продолжения банкета.

Теперь переходим к собственно сборке.

Штатно сборка MarkText происходит вызовом команды yarn build, но если посмотреть внутрь файла package.json, в котором находятся все команды сборки, увидим:

..
"build": "node .electron-vue/build.js && electron-builder",
..

Вызов electron-builder очевидно упадет, поскольку он не был портирован на FreeBSD и плотно завязан на готовые бинарные части и ветвления логики под конкретную поддерживаемую ОС.

Так что вызываем лишь первую часть, причем вручную (без всяких yarn):

node .electron-vue/build.js

Должен отработать webpack, sass и в каталоге dist будет находиться готовое к запуску приложение на Electron.

К сожалению в «обнаженном» виде, без прилепленного рантайма, что однако никак не мешает его запустить:

electron37 dist/electron/main.js

Так выглядит запущенный MarkText на FreeBSD, в работе над английскими версиями статей:

Для удобства использования можно перенести каталоги dist и node_modules в отдельное место:

И запускать вот таким скриптом:

#!/bin/sh

/usr/local/bin/electron37 dist/electron/main.js

Готовый архив со сборкой можно скачать в нашем Телеграм-канале.

Update 02.05.2026

С момента написания статьи в FreeBSD появилась обновленная версия Electron 3.9, несовместимая с 3.7, пакет с которой еще и удалили.

Что еще печальней, сам Marktext работает с еще более старой версией, зависящей от устаревшей Node.js 18, биндинги к которой более не совместимы с 25 и выше в новом Electron.

Поэтому собирать придется с помощью Node 22:

pkg install node22 electron39 npm-node22 

Второй печальный нюанс — блокировка ресурсов ElectronJS для доступа из РФ, поэтому для сборки, во время которой присходит скачивание заголовков Node.js необходимо выставить прокси:

yarn config set httpsProxy 103.131.232.9:8080

Для отладки:

export DEBUG=electron-rebuild

Для проверки скачивания архива с заголовками:

wget -e use_proxy=yes -e https_proxy=103.131.232.9:8080 https://artifacts.electronjs.org/headers/dist/v18.0.4/node-v18.0.4-headers.tar.gz

Но это еще не все.

Собранная с таким трудом сборка упадет при запуске с вот такой ошибкой:

TypeError: features.isDesktopCapturerEnabled is not a function

Чтобы ее увидеть надо задать две переменные окружения:

 export ELECTRON_ENABLE_LOGGING=1
 export ELECTRON_ENABLE_STACK_DUMPING=1

Для исправления необходимо закомментировать два блока в конце файла @electron/remote/dist/src/common/module-names.js:

const features = get_electron_binding_1.getElectronBinding('features');
/*if (!features || features.isDesktopCapturerEnabled()) {
    exports.browserModuleNames.push('desktopCapturer');
}*/
/*if (!features || features.isViewApiEnabled()) {
    exports.browserModuleNames.push('ImageView');
}*/

которые и порождают ошибку.

Конечно это адский костыль и времененное решение, но обновлять Marktext целиком на новую версию Electron — сил не хватит.