Практически у каждого материала о Linux разгорается нешуточная, хотя местами и шутливая дискуссия. Комментаторы не гнушаются даже самых грязных приёмов: уход от темы, манипуляции, недоговорки и, о ужас, статистика! Что ж, давайте попробуем поиграть на их поле и по их правилам: разберем все традиционные аргументы в пользу Linux — и посмотрим, что общего они имеют с реальностью.

— Ух ты, у тебя пять звезд на лоре.

ivlad, L.O.R Quotes

4.3, 4.2

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

Давайте рассмотрим наиболее часто встречающиеся аргументы и ошибки с их стороны. Но только про Linux, причём полноценный десктопный! И немного про Open Source в целом. Можно очень долго рассказывать, как всё плохо с той или иной не Linux-based ОС или программой, но Linux от этого лучше (или хуже) не станет. Можно столь же долго убеждать, что «у меня всё работает», или обвинять в некомпетентности оппонента, но от этого тоже ничего не изменится. А можно наконец признать, что проблемы есть и что средний пользователь справиться с ними не в состоянии.

⇡#Аргумент 1: Linux везде

Или, проще говоря, Linux уже победил, так что можно сидеть спокойно, не переживать и наслаждаться победой. Тут обычно вспоминают встраиваемые решения или — в общем случае — какие-то готовые продукты (чаще говорят про сетевые), а также Android и суперкомпьютеры с серверами.

Убедиться в правдивости этих утверждений несложно — в отчёте о разработке ядра Linux за 2017 год приводятся следующие цифры: 90% рабочих приложений в публичных облаках работают с ОС на базе Linux, на рынке встраиваемых решений доля этого типа ОС составляет 62%, а на рынке суперкомпьютеров — все 99% (сейчас, конечно, и того больше). Наконец, 82% смартфонов в мире используют ядро Linux, как и 9 из топ-10 публичных облаков.

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

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

С Android история точно такая же. В основе, конечно, тоже ядро Linux, но подавляющее большинство приложений взаимодействует в первую очередь с Android Runtime (ART), а не с ядром. Собственно, это самое ядро тоже во многом отличается от основной ветки, а тот же ART уже портирован на Google Fuchsia. Так что, если в какой-то момент разработчики решат переехать с ядра Linux на любую другую платформу, конечному пользователю наверняка будет всё равно.

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

⇡#Аргумент 2: Linux бесплатен

Корректнее было бы сказать, что Linux выгоднее или, допустим, дешевле других решений. Но никакого возвышенного альтруизма и высокой духовности тут нет. Если вы не платите прямо сейчас за загрузку iso-образа и использование какого-нибудь дистрибутива, то это не значит, что вы не платите вообще. На уровне пользователя или даже компании переход на Linux всё равно выливается во временные затраты на освоение и поддержку системы, а время — деньги, как бы банально это ни звучало. И это, на мой взгляд, один их ключевых сдерживающих факторов.

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

Многие мажорные и самостоятельные, то есть в достаточной степени отличающиеся от других, современные дистрибутивы либо имеют бесплатные и коммерческие (сюда же входит поддержка) версии, либо прямо или косвенно спонсируются другими компаниями, институтами, государством, а также частными лицами. Для примера: в 2018 году только в рамках SPI на Debian пришлось $335 тыс., а на Arch Linux $294 тыс. И это норма для бесплатных на первый взгляд проектов. В частности, Document Foundation (LibreOffice) обходится в €700-800 тыс. в год, OSI тратит несколько сотен тысяч долларов, а Linux Foundation, ключевая организация в мире Linux, стремительно наращивает обороты — в 2017 году она получила более $80 млн.

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

Последний вариант особенно интересен в отношении ядра Linux, которое ведь основа всего. Обратимся всё к тому же отчёту за 2017 год. Вклад действительно независимых разработчиков, без финансовой поддержки с чьей-либо стороны, составил 8,2 %. С некоторой натяжкой к ним можно добавить ещё 4,1 % от тех, для кого не удалось достоверно узнать о наличии спонсорства. Всё остальное — вклад коммерческих компаний, вполне себе платными продуктами которых вы прямо или косвенно пользуетесь, частично оплачивая таким образом и разработку Linux.

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

⇡#Аргумент 3: Linux свободен

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

Например, в 2004 году у XFree86, которым почти 13 лет пользовались практически все, внезапно сменилась лицензия, что всем не понравилось. Незадолго до официальной смены был сделан форк. И это нормально. Нормально и наличие нескольких независимых и взаимозаменяемых реализаций корневых компонентов — посмотрите на musl или LibreSSL, например. Это разумно для поддержания безопасности и стабильности. И это не самое плохое проявление NIH-синдрома.

Ненормальны истории вроде той, что произошла с Libav, когда часть команды из-за отчасти личных разногласий покинула FFmpeg и сделал его форк — собственно Libav, заодно предъявив права на логотип. Хуже того, в команде оказался мейнтейнер FFmpeg в Debian и Ubuntu, так что в этих дистрибутивах и их деривативах оказался именно Libav. В итоге через несколько лет они всё равно вернулись к FFmpeg. Нельзя сказать, что Libav оказался чем-то принципиально лучше. Да и вся история не слишком красивая.

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

В случае десктопного Linux речь не только о противостоянии Qt и GTK или Gnome и KDE, которые в значительной мере дублируют друг друга в плане функциональности, а о каких-то корневых вещах. Уже лет пять постоянно идут разговоры, что вот-вот, уже прямо сейчас все переберутся с «иксов» на Wayland, а пока в качестве костыля есть XWayland. И про Mutter, KWin и переобувшийся на лету Mir от Canonical тоже не забудем. Глядишь, скоро приложения с разными тулкитами действительно будут вести себя одинаково и выглядеть единообразно. В конце концов, со звуком же как-то справились, и десяти лет не прошло.

С ядром в этом отношении попроще, так как управление разработкой во многом носит авторитарный характер. Регулярно появляются жалобы, что в основную ветку ядра не принимают те или иные патчи, так как постоянная поддержка актуальной версии ядра с собственными доработками со временем становится всё затратней. И именно поэтому Google уже больше десяти лет жаждет, чтобы ее модификации для Android попали в основную ветку. Чтобы было поменьше самодеятельности, как в случае патчей «безопасности» Samsung.

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

Ну и нельзя не упомянуть о самом «спорном» системообразующем проекте десятилетия — systemd. Одни называют его благословлением, другие проклятием. Причем по одной и той же причине: он достаточно глубоко интегрируется в систему и позволяет контролировать очень многое. Как бы то ни было, основной разработкой занимается одна компания, но при этом systemd сейчас используют практически все ключевые дистрибутивы. Основное опасение в том, что, пусть косвенно, пусть не сразу, но определять дальнейшее развитие ОС будет вполне конкретная корпорация и узкий круг людей.

⇡#Аргумент 4: Linux безопасен

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

Если говорить про софт, то есть просто таки классические примеры: баг 25-летней давности, баг 33-летней выдержки и, наконец, ещё одна пара, 37 и 36 лет от роду. Все они появились ещё во времена BSD и перекочевали в их наследников. Все эти годы исходники были доступны великому множеству людей, что не помешало багам успешно дожить до наших дней.

Статистика обнаруженных уязвимостей ядра Linux неумолима: всего 3 критических, которые в среднем присутствуют 5,2 года; 44 высокого уровня со средним сроком 6,2 года; дыр среднего уровня опасности набралось 404 штуки, а «живут» они 5,3 года; низкого уровня всего 216 — и 5,5 лет соответственно. Предыдущее исследование также показало средний срок существования уязвимости на уровне 5 лет.

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

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

Кстати, давно вы по доброй воле возились с polkit или apparmor, например? А с файерволлом, который по умолчанию много где даже не настроен? Или доверяете параметрам от разработчиков? А бинарные файлы или пакеты из сторонних источников антивирусом проверяете? Или он вам действительно не нужен?

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

⇡#Аргумент 5: в Linux лучший способ распространения ПО

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

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

При этом у пользователя даже в рамках стандартной пакетной базы выбор небольшой: либо использовать устаревшее, но стабильное ПО, либо обратиться к модели rolling release, получая свежие программы, но ограничиваясь относительно малой официальной пакетной базой и доверяя сторонним источникам. Мало кому удаётся соблюсти хороший баланс. Дополнительные механизмы для поддержания стабильности вроде снапшотов со временем начинают отъедать место.

В качестве неизбежной альтернативы в итоге появились portable-форматы, о едином стандарте которых тоже так и не смогли договориться: существуют Flatpak, Snappy и AppImage. Устроены они в целом по принципу «всё своё ношу с собой», что сказывается на размерах. Когда их всего несколько штук в системе, а это зачастую самый простой способ получения актуальной версии программ, то всё удобно. Проблема доверия к источникам ПО остаётся, так как централизованных больших магазинов, для которых такие форматы идеальны, с проверкой и модерацией просто нет.

⇡#Аргумент 6: в Linux нет проблем с ПО

Тут часто вспоминают, что в репозиториях находится очень много ПО. Например, для Debian Buster официально предлагается чуть больше 89 тысяч пакетов. Однако из них 43 тысяч с хвостиком приходится на dev/src/dbg-пакеты и почти 6 тыс. относится к doc и data, то есть к сопутствующим для программ пакетов. Если грубо прикинуть, около половины всего списка пакетов приходится на библиотеки. Потому что именно так принято разбивать необходимые для установки файлы, что бывает очень удобно.

Казалось бы, число огромное! Но это не имеет никакого значения, если нужной программы нет. Можно сколько угодно рассказывать о том, что под Linux существуют аналоги любого ПО, но это не так. И сколько угодно говорить, что GIMP даже лучше Photoshop, а LibreOffice почти как MS Office, но это тоже не так. Это разные программы, с разной функциональностью, с разным подходом к пользовательскому опыту. И это нормально! Но в силу всё той же малой доли, фрагментации и особенностей дистрибуции, десктопного ПО сравнительно немного, а кроссплатформенных программ ещё меньше.

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

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

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

⇡#Аргумент 7: Linux эффективнее работает с ресурсами

Это крайне спорное утверждение, особенно в случае десктопа. Очень многое зависит скорее от «кривости» программ, нежели от самого ядра. Но и оно не идеально. Давняя проблема работы при низком объёме свободной RAM периодически всплывает снова и снова. Так что мы, похоже, таки дождёмся момента, когда OOM-менеджеры будут ставить по умолчанию. Да что там, практически для любой подсистемы можно посмотреть патчи за последние пару-тройку лет, чтобы убедиться, что для ускорения почти всегда есть возможности.

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

⇡#Аргумент 8: Linux удобен

Но только если конкретно вам удобен. Если смотреть в целом, то никаких гениальных интерфейсных решений, которые невозможно было бы получить в других ОС, в последние годы на десктопе нет. А вот раздражающих мелочей донельзя много. В 2020 году всё ещё можно нарваться на проблемы с настройкой переключения раскладки клавиатуры, на отсутствие аппаратного ускорения воспроизведения в браузере по умолчанию, на проблемы с гибернацией, на проблемы переключения между интегрированной и дискретной графикой, на ещё какие-нибудь проблемы… Можно долго перечислять.

Но… всем плевать. Почему? Потому что, как и говорилось в самом начале, разработчики и пользователи десктопного Linux всё сильнее отдаляются друг от друга. Первые зачастую свято уверены в том, что они лучше знают, что надо вторым, а вторые ничего толком с этим поделать не могут. В последние годы наблюдаются уже просто две крайности. GNOME последовательно и методично «упрощается», лишаясь не только ряда настроек, но и привычных концепций работы с окнами. KDE не менее последовательно возится с какими-то мелочами, подолгу игнорируя реальные проблемы. Альтернативные же решения попросту не обладают достаточным числом разработчиков для быстрого развития.

⇡#А что ты сделал для десктопа в свои годы?

В 2005 году проект GNOME поставил перед собой цель: достичь 10 % на рынке десктопов. Прошло 15 лет — и ничего не изменилось. Фрагментация, нежелание координировать усилия, NIH-синдром, всё большее удаление разработчиков от пользователей — это, получается, и есть та, свобода, за которую стоило бороться? Почему так произошло? Потому что мир успел измениться. Причины всех бед скорее социальные, нежели технические.

Ilya Korneychuk@iKorneychuk

Is that the spirit of @OpenSourceOrg ? @gnome banned me after I have criticized their UI.

20

03:33 - 17 февр. 2020 г.

Информация о рекламе в Твиттере и конфиденциальность

Смотреть другие твиты Ilya Korneychuk

Кто в этом виноват? Мы! Linux — замечательная, универсальная, гибкая и мощная операционная система с, увы, уже не самым лучшим сообществом вокруг. Не надо говорить, как всё плохо в других ОС и как всё замечательно в Linux. Надо говорить, как всё обстоит на самом деле. Не нужно говорить «а у меня всё работает», лучше рассказать, как этого добиться. И не отправляя в сторону RTFM, а объясняя — это образование и самообразование. Не нужно мириться с ошибками, о них нужно сообщать.

Впрочем, вам, конечно, никто ничего не должен. И вы никому ничего не должны. Все свободны!

https://3dnews.ru/1005287/linux-pros-and-cons