Живучесть софта на примере дистрибьютивов Linux
Я уже старенький и работаю с этими вашими линуксами очень давно, успел потрогать за мягкое место практически все популярные дистрибьютивы. Некоторые из них стабильно умирали через неделю-месяц, какие-то жили годами, в паре случаев установленная ОС выжила и продолжает работать до сих пор, после 10+ лет с момента установки.
Ниже будут мои наблюдения на тему живучести, что именно позволяет сложному софту выживать и процветать а что загоняет в могилу раньше времени.
Предания старины глубокой
Дистрибьютив Linux — отличный пример сложного созависимого софта, на примере которого можно оценивать перспективы собственных разработок.
Начну как обычно с истории, вот такой командой:
stat / | grep "Birth" | sed 's/Birth: //g' | cut -b 2-11
можно определить дату установки каждого конкретного линукса.
На машине, с которой я сейчас пишу эту статью эта команда выдает:
2017-09-10
То есть работающая и ежедневно используемая система была установлена 6 лет назад, пережив все обновления, патчи, новые ядра и библиотеки.
Причем это машина разработчика, ноутбук, на котором постоянно происходят установки и удаления разнообразного софта.
В том числе и ваш любимые Node.js с Python, чьи обновления стабильно ломают все вокруг.
Вообщем-то 6 лет далеко не рекорд, у меня есть машины с 10+ лет истории, где установленная ОС была перемещена с другого ноутбука.
Чтобы такое долгожительство было возможным, необходимо по моим наблюдениям несколько вещей.
Первое: консервативность
В первую очередь консервативность в плане выбора системных библиотек и фреймворков, нежелание внедрять еще необкатанные новшества.
Есть например такая штука systemd, отвечает за загрузку и запуск системных сервисов в современных линуксах.
К сожалению до того как стать стабильной и надежной, systemd прошла очень длинный и непростой путь, наделав по дороге огромное количество проблем своим пользователям.
Очевидно что дистрибьютивы линукса, первыми внедрившие systemd (Fedora, Gentoo) — первыми и собрали все ее баги.
Заниматься отладкой подобных штук в домашних условиях неподготовленному человеку нереально, поэтому практический смысл тратить на это время отсутствует.
Работает что характерно не только в ИТ.
Второе: отсутствие «уникальных технологий»
Существуют много «сборок» линукса новой волны, где главный смысл это некий уникальный пакетный менеджер или даже целое графическое окружение, написанное с нуля под этот проект.
Вроде такого:
Rather than using a traditional Linux package management system, Endless OS uses a read-only root file system managed by OSTree with application bundles overlaid on top.
Или такого:
Solus is a Linux distribution built from scratch. It uses a forked version of the PiSi package manager, maintained as "eopkg" within Solus, and a custom desktop environment called "Budgie", developed in-house.
Практика использования показывает что подобные решения не выживают.
По крайней мере все подобные «наколенные» сборки у меня не пережили даже года использования.
Как только ОС перестает выполнять свою работу и пытается диктовать условия использования клиентскому ПО — на этом все, можно звать похоронную команду.
Вам все равно будет нужно и KDE и Gnome и даже Xfce (хотя-бы для стороннего софта, который часто про другие DE просто не знает), будут нужны стандартные компиляторы и средства разработки.
Поэтому сколько бы различий не было на начальном этапе, через год все приходит к одному и тому же набору софта, где есть все графические библиотеки, все основные DE и ключевые средства разработки.
Есть исключения, вроде Puppy Linux или Kali, но эти сборки не рассчитаны на постоянное использование, а являются своеобразным инструментом, поэтому в большинстве случаев остаются в том виде в котором поставляются.
Третье: «Несистемно-системный» софт
В моей любимой Mageia, которая как раз и является главным долгожителем на моих машинах, весь системный софт написан на Perl, в том числе вот такая панель управления:
Фишка в том что Perl — сам по себе очень старый язык, оформившийся и ставший стабильным еще в 90е, к которому десятилетиями не выходят «ломающие обновления».
Поэтому шанс на то что какая-то часть системного софта сломается при обновлении системного же Perl — в районе нуля.
По крайней мере на моей практике (а я использую Mandriva/Mageia с 2008го года) такого не было.
Для сравнения — в суперпопулярной Ubuntu основной язык для системного софта это Python, в том числе на нем написан их Software Center:
Одного этого факта хватает для постоянных поломок ОС,потому что сам Python постоянно активно развивается и меняется, часто без оглядки на обратную совместимость.
Плюс очевидный постоянный риск сломать системную версию установленной вручную из-за требований очередного проекта.
С Perl такого произойти просто не может.
Вообщем Ubuntu никогда не жила у меня дольше чем пару лет, дальше следовал снос и переустановка с чистого листа.
Четвертое: соблюдение норм и стандартов
С момента появления и распространения Линукса прошло уже достаточно времени чтобы у его пользователей выработались определенные привычки и паттерны поведения.
Другими словами пользователи линукса в большинстве своем представляют чего они хотят и как это получить.
В тоже время Юникс как и Линукс в виде его продолжения позволяет большую гибкость в настройках, расположении ключевых файлов и библиотек, проще говоря:
существует куча способов поставить системную утилиту или библиотеку Х не туда где ее будут искать или заменить ее на Y
И существуют дистрибьютивы где этим активно пользуются и «все совсем не так» как у нормальных людей.
Два ярких примера для иллюстрации это SUSE и Slackware. Оба что характерно являются частыми темами для линуксоидных анектодов, срачей и общего неадекватного поведения.
Причина тому (по моим наблюдениям) как раз в глобальном расхождении с общепринятой практикой использования.
Например в SUSE практически все системные утилиты отличаются от общепринятых, а в Slackware до недавних пор даже не было пакетного менеджера и поощрялась установка софта и библиотек вручную, с ручным же разруливанием зависимостей.
Накал дичи с годами конечно снижается и «слака» уже совсем не та и «зюзе-роутер» стал куда ближе к стандартам, чем было скажем 10 лет назад.
Но концепция не поменялась, поэтому пользователи этих двух дистрибьютивов по большому счету все также варятся в собственном мирке, со своими специфичными проблемами и решениями, неработающими для остальных дистрибьютивов.
Что касается моего опыта, то что SUSE что Slackware я перестал как-либо использовать очень давно и не могу рекомендовать их кому-бы то ни было, как раз по причине специфичности — в какой-то момент вы просто останетесь с проблемами один на один.
Причем проблемы там на уровне работы с отладчиком и компилятором, без опыта и с полпинка не решить.
Нельзя сказать что Slackware или тем более SUSE прямо умирают и завтра закончат свои дни, но круг их пользователей точно мог быть шире, если бы не намеренная ориентация на свою специфику.
Которая (если откинуть весь фанатизм) не особо кому и нужна.
Послесловие
Соотнося весь свой опыт использования различных дистрибьютивов линукса, могу сказать что лично у меня выжили лишь те сборки, которые не мешали мне жить и работать, ну и разумеется не создавали больше проблем чем решали.
Если любое обновление приносит какие-то дикие, сложно решаемые проблемы, которые требуют многочасового гугления, чтения статей и руководств — смысла использовать такой софт долгое время просто нет.
Надеюсь озвученные выводы помогут вам в более адекватной оценке собственного софта и мнения пользователей, по крайней мере лично для моих разработок такая «ретроспектива выживаемости» дала определенную пищу для размышлений.