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

«Разрешения» файлов

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

Может по началу это было важно для разработчика, но как пользователь, я просто не стал забивать себе голову расширенными вариантами. Не знаю, может для профессионалов linux это разнообразие имеет более острое значение?

Вторая проблема, опять же, связана с «разрешениями», причём не только для доступа к
файлам, но и к устройствам. Например, устанавливаешь программу и не можешь понять —
почему она не работает как ожидается? Ответ может оказаться неожиданным: неправильно
выставлены права на «файлы»! И это при том, что есть, худо‑бедно, «установщик», который
вроде бы и должен был решить эту задачу. Но почему‑то не смог.

Заслуживает внимания и алгоритм изменения «разрешений». Сама команда для задания
разрешений изменяет их везде, где может дотянуться, исходя из прав текущего пользователя.
Это настолько неудобно, что, как минимум, приходится выполнять две команды:
сначала изменить права на всё, а потом выискивать файлы‑каталоги, чтобы задать им
разрешения на «исполнение». (Этот метод есть в сети интернет, за что автору моя
признательность.)

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

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

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

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

Файловые системы

Ещё хочется отметить надёжность файловых систем ex4 и, по‑моему, fuse — драйвер доступа к разделам ntfs.
«Спасибо», разработчики, за всё время пользования разнообразными накопителями данных, именно в linux — хорошо, в двух ОС на его основе — я внезапно терял файлы.

Понятно, что это были съёмные диски, надёжность ниже и так далее… Но всё же я не припомню, чтобы на windows были такие проблемы. Хотя должен сразу отметить, что сбои с потерей файлов
бывают и у ntfs.

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

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

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

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

Репозитории и обновление

Разумеется разработчики GNU/linux периодически пытаются исправлять ошибки и обновлять своё детище.

Но и здесь всё настолько плохо, что для проблемы обновлений дали название — «ад зависимостей». Но самое удивительное то, что за тридцать с лишним лет для linux не придумали что‑то лучше.

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

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

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

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

Интересная деталь: Долгое время линукс использовался только на серверных ЭВМ и якобы был просто не интересен рядовым пользователям. И вот только когда домашние ПК стали
достаточно мощными…

На самом деле, проблема была в другом, изначально GNU/linux был жёстко привязан к сетевому адаптеру компьютера. А на домашних ПК сетевые карты до какого‑то момента были редкостью. Так что установленный линукс тупо показывал чёрный экран…
Вероятно, на новых процессорах, имеющих специальные таймеры, эта проблема была решена.

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

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

Кстати, есть очень точное описание linux, которое всё объясняет:

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

Примечание: Это была, так называемая, вводная. Я не собираюсь впустую перебирать проблемы существующих ОС. Я попробую описать модель Системы, которая должна использовать накопленный за десятки лет опыт. (Естественно, отдельные не очевидные новшества я придержу на будущее, для себя.)