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

35 лет ядру Linux: рефлексия системных проблем и практического опыта

В этом году ядру Linux исполняется тридцать пять лет. Официальной точкой отсчёта в истории проекта принято считать 17 сентября 1991 года, когда молодой финский студент Линус Торвальдс выложил исходные тексты своей разработки в публичный доступ для узкого круга специалистов. За прошедшие три с лишним десятка лет операционные системы на базе ядра GNU/Linux прошли огромный путь, превратившись из нишевого энтузиастского проекта в основу мировой серверной инфраструктуры, суперкомпьютеров и мобильных платформ. Однако круглый юбилей — это отличный повод не только вспомнить истории успеха, но и трезво оценить практическую сторону использования этой экосистемы.

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

«Разрешения» файлов и разграничение прав доступа

Первый серьезный барьер, с которым я столкнулся при детальном освоении Linux, связан с системой разграничения прав и разрешений. Меня всегда удивляло, зачем разработчикам потребовалось создавать сразу несколько форматов записи этих параметров в параметрах консольных команд — от символьных обозначений до восьмеричных числовых кодов. Да, для наглядного отображения в логах или консольном листинге разный формат вывода вполне оправдан. Но когда речь заходит об оперативных командах управления, такая вариативность создаёт избыточную сложность на ровном месте.

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

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

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

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

Надежность файловых систем и особенности работы с дисками

Отдельный важный вопрос — это надежность файловой системы ext4 и специфика работы драйвера FUSE при монтировании разделов NTFS. За всё время работы с различными накопителями именно в системах на базе Linux я неоднократно сталкивался с неприятными ситуациями внезапной потери данных.

Безусловно, внешние съемные диски, подключаемые по USB, априори менее надежны из-за возможного нестабильного контакта или сбоев питания. Но на платформах Windows подобных критических сбоев с массовым исчезновением файлов на ровном месте я не припомню, хотя и у NTFS случаются свои проблемы. В Linux мы часто имеем дело либо с плавающими ошибками в коде драйверов, либо с некорректной реализацией логики работы с файловыми журналами.

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

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

Репозитории, пакетный менеджмент и «ад зависимостей»

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

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

Предварительный вывод и исторический контекст

Итоговый вывод выглядит достаточно сдержанно: за три с лишним десятка лет монолитное ядро GNU/Linux трансформировалось в громоздкую систему, создающую избыточную нагрузку на пользователей, разработчиков и администраторов. На этапе зарождения монолитная архитектура была прорывом, но сегодня она всё больше напоминает попытку построить космический корабль на базе парового двигателя конца XIX века.

Интересный исторический факт: длительное время считалось, что Linux не прижился на домашних ПК из-за своей сложности и ориентации исключительно на серверные ЭВМ. На самом деле причина кроется в другом. Первоначально ядро Linux имело жесткую архитектурную привязку к наличию сетевого адаптера и его аппаратным таймерам. На домашних компьютерах 1990-х годов сетевые карты встречались крайне редко, из-за чего свежеустановленная ОС просто выдавала черный экран при загрузке. Проблема разрешилась только тогда, когда в новых процессорах появились встроенные таймеры.

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

Сложившуюся ситуацию отлично иллюстрируют образы из популярной мультипликации: Linux напоминает самодельную машину Волка из 14-го выпуска «Ну, погоди!», собранную из подручных средств и требующую постоянной наладки, тогда как современная Windows похожа на космическую ракету из того же выпуска — мощную, но крайне громоздкую. В перспективе я планирую представить собственную концептуальную модель операционной системы, которая учтет тридцатилетний опыт индустрии и исправит ключевые системные изъяны.

Сервисные новости: отложенные поездки в «Яндекс Go» ради скидки

В завершение стоит упомянуть интересное обновление в сфере цифровых сервисов. Сервис «Яндекс Go» анонсировал новую функциональность для пассажиров — опцию «Позже». В периоды высокого спроса, когда стоимость поездок на такси существенно возрастает из-за динамического коэффициента, пользователям предложат отложить вызов машины на 30–40 минут. За согласие подождать сервис предоставляет ощутимую скидку на поездку. Важно отметить, что скидка финансируется полностью за счёт «Яндекс Go» и не снижает итоговый доход водителя.

Источник: habr.com