Про течение времени и обратную совместимость

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

Автор мягко говоря не геймер и вообще достаточно редко использует «пользовательские» ОС вроде Windows или Mac, но и с такими вводными — все чаще замечаю, что работа с даже слегка устаревшим ПО с каждым годом все больше усложняется.

И что самое интересное:

Вбейте в любимый поисковик «warcraft 3 crashing» и с удивлением обнаружите, что ни один из вариантов решения в выдаче более не работает (спасибо последнему патчу для Windows 11).

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

Вы же не ожидаете падений с последующим ковырянием отладчиком стандартной «Косынки» или «Блокнота»?

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

Так что оно просто обязано работать:

Warcraft 3 спокойно работал на линуксах под Wine чуть ли не с первых дней, но теперь имеет проблемы с запуском в современной Windows 11.

Думаю вы догадываетесь, что для вашего типичного корпоративного ПО шанс пережить десятилетие сильно меньше.

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

Планета софта

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

Внутренняя реализация ОС со всеми изменениями — магма, все человеческие постройки от пирамид (легаси) и до современных небоскребов будут представлять прикладное ПО.

Что произойдет при выбросе магмы на поверхность?

Извержение вулкана, которое поменяет ланшафт и сметет нахрен все человеческие постройки.

Прямой аналог — BSOD или Kernel Panic в мире ПО.

Что будет если ланшафт немного поменяется?

Ничего хорошего.

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

Примерно такой:

А ваш драгоценный софт, это например здание, стоящее рядом с этой дырой в земле.

Как и настоящая планета, наша «планета софта» тоже постоянно изменяется и процесс этот давно не поддается ни оценке ни какому-либо контролю.

Серьезно:

Скромно молчу про более обывательские ОС.

И такими дикими темпами сейчас обновляется вообще все:

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

В качестве иллюстрации, небольшой отрывок из длинного списка релизов порта OpenJDK 17 для FreeBSD за прошлый год:

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

И это только одна 17я версия пакета JDK — далеко не самого важного или часто используемого в реалиях FreeBSD.

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

Вот так выглядит небольшая выдержка (видите 8 страниц да?) из списка релизов порта браузера Chromium для FreeBSD:

По релизу в неделю!

В неделю, Карл.

Чтобы вы понимали, сборка Chromium из исходников занимает часов 8-10 даже на мощной машине и требует огромного количества ресурсов. Там настолько чудовищный объем исходного кода, что потеряться может целая команда разработки. Даже не одна.

При этом:

Все также из-за сочетания темпов разработки и объемов исходного кода.

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

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

Он должен быть обязательно и обязательно должен работать.

Правда весело?

Разумеется такие дикие темпы приводят к серьезным ошибкам:

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

Причины

Думаю теперь вам хочется узнать почему половина айтишников п#дорасы так происходит и все так плохо.

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

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

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

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

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

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

С коммерческими проектами все обстоит несколько иначе:

Если у вас есть деньги и жгучая попу потребность обеспечить «чтоб работало» даже через двадцать или тридцать лет после создания ПО — вам помогут:

Intel до сих пор продает малыми партиями и на заказ устаревшие процессоры, Microsoft до сих пор оказывает поддержку своих устаревших ОС — разумеется за деньги. Большие.

Знаю случаи, когда всеми доступными средствами обеспечивали работоспособность устаревшего ПО, работающего еще на Windows 3.1, вплоть до закупки под заказ устаревшего железа.

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

Отсюда же растут уши и современного использования COBOL с мейнфреймами:

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

Держать подобное ПО в режиме поддержки дольше 10-15 лет просто нерентабельно — он быстро «тяжелеет» и обрастает костылями.

С пользовательским ПО для широких масс дела обстоят еще веселее — такой софт в современных реалиях намертво зависит от операционной системы и ее обновлений.

Поэтому если до мастшаба Adobe Photoshop/SolidWorks еще не доросли — вам придется привязываться к релизам ОС и постоянно тестировать ваш софт на всех новых версиях и подстраиваться под изменения, потому как производитель ОС вам навстречу не пойдет.

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

Проще «в приказном порядке» постоянно просить всех обновляться.

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

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

Угар безопасности

Для начала стоит показать вот такой замечательный скриншот:

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

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

Каждая такая уязвимость это минимум вывод из строя (DDoS), как максимум — удаленный доступ (RCE) к взломанному серверу.

Другими словами, ситуация с ИБ в современном мире это один сплошной кромешный п#здец:

Малейшее устаревание, пропуск обновлений и забивание на ИБ и все — ваши данные уже гуляют по интернету, сеть взломана, бекапы зашифрованы, а с вас вымогают круглую сумму за «решение вопроса».

Это не преувеличение или нагнетание, а самая настоящая реальность:

вспоминается случай 2015го года, когда разворачивали проект в облаке AWS и в течение часа в интернет был выставлен ненастроенный стандартный Apache Tomcat.

Буквально развернули ОС, поставили Tomcat и ушли на обед, на час.

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

Один блин час в открытой сети!

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

Пути исправления

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

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

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

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

Миграция и доработки

Самый оптимальный вариант если ПО не успело устареть больше чем на 10-15 лет и особенно если оно создано на базе managed-платформы вроде JVM или .NET:

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

С нативными приложениями на C/C++/Golang или (боже упаси) Rust все куда сложнее:

такие проекты зависят от внешних библиотек, тоже нативных и со своим циклом разработки.

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

Вы убьетесь решать проблемы с например устаревшим WebKit или FFMpeg — наиболее часто используемыми библиотеками.

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

Поэтому долговременная поддержка нативного проекта это всегда лотерея, где казино (которое всегда в выигрыше) это не вы.

Эмуляция

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

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

Теория гласит:

Что же получается на практике?

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

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

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

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

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

Переписывание

Характерно и вообще физически возможно для небольших проектов.

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

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

Эпилог

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

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

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

Но несет настолько адские риски, что на такое не идут даже самые лютые «резатели костов»:

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

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

А в какой-то момент встанет вопрос еще и устаревания аппаратной части:

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

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

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