Unix way что это

UNIX way

Содержание

МакИлрой: Четверть века UNIX

Дуг МакИлрой, изобретатель каналов UNIX и один из основателей традиции UNIX, обобщил философию следующим образом:

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

Обычно эти высказывания сводятся к одному «Делайте одну вещь, но делайте её хорошо».

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

Пайк: Стиль программирования на C

Роб Пайк (англ. Rob Pike ) предложил следующие «правила» в качестве аксиом программирования. [1] Одновременно эти правила могут выражать точку зрения на философию UNIX:

Первое и второе правила Пайка перефразированы Тони Хоаром (англ. Tony Hoare ) в известную аксиому «Преждевременная оптимизация — корень всех зол». Кен Томпсон (англ. Ken Thompson ) перефразировал 3 и 4 правила Пайка так: «Если сомневаетесь, используйте перебор всех возможных комбинаций». Правила 3 и 4 являются частными положениями философии дизайна KISS: Keep It Simple, Stupid (будь попроще, тупица). Правило 5 было предварительно сформулировано Фредом Бруксом (англ. Fred Brooks ) в книге «Мифический человеко-месяц». Правило 5 часто сокращают до «пиши тупой код, который использует умные данные». Правило 6 взято из шутки Брюса, прозвучавшей в «Летающем цирке Монти Пайтона».

Майк Ганцарз: Философия UNIX

В 1994 году Майк Ганцарз (англ. Mike Gancarz ) объединил свой опыт работы в UNIX (он является членом команды по разработке системы X Window System) с высказываниями из прений, в которых он участвовал со своими приятелями программистами и людьми из других областей деятельности, так или иначе зависящих от UNIX, для создания Философии UNIX, которая сводится к 9 основным принципам:

Менее важные 10 принципов не снискали всеобщего признания в качестве частей философии UNIX и в некоторых случаях являлись предметом горячих споров (монолитное ядро против микроядра):

Реймонд: Искусство программирования в UNIX

Эрик С. Рэймонд (англ. Eric S. Raymond ) в своей книге «Искусство программирования в UNIX» подытожил философию UNIX как широко используемую инженерную философию «Будь попроще, тупица» (Принцип KISS). Затем он описал, как эта обобщенная философия применима в качестве культурных норм UNIX. И это несмотря на то, что несложно найти несколько нарушений в следующей текущей философии UNIX:

Большинство из этих норм принимается вне сообщества UNIX — даже если это было не так во времена, когда они впервые были применены в UNIX, то впоследствии это стало так. К тому же много правил не являются уникальными или оригинальными для сообщества UNIX. Тем не менее, приверженцы программирования в UNIX склоняются к тому, чтобы принять комбинацию этих идей в качестве основ для стиля UNIX.

Цитаты

Критика

Философия UNIX критиковалась в книге «The UNIX Haters Handsbook», написанной сотрудниками компании Microsoft в начале 1990х годов.

По их мнению, подход UNIX приводит к появлению решений, сделанных наспех, без должного продумывания архитектуры, после чего данные решения канонизируются (enshrined), то есть объявляются вечной классикой. Например, таким решением, по их мнению, являются lock files — временные файлы без содержимого, создаваемые как пометка того факта, что какая-то программа находится в процессе исполнения.

Так, например, ими критиковалась X Window System за отделение в ней движка от политики, что привело к отсутствию в UNIX стандарта на политики управления пользовательским интерфейсом и большим затруднениям при разработке приложений, использующих GUI.

Приводился ряд примеров, показывающих, что некоторые решения, принятые в ОС VMS, Microsoft Windows и Apple Mac OS, значительно превосходят своих аналогов из мира UNIX.

Примечания

См. также

Ссылки

Полезное

Смотреть что такое «UNIX way» в других словарях:

Unix way — Философия UNIX это набор культурных норм и философских подходов к разработке программного обеспечения, основанных на опыте ведущих разработчиков операционной системы Содержание 1 МакИлрой: Четверть века UNIX 2 Пайк: Стиль программирования на C … Википедия

Unix time — Unix time, or POSIX time, is a system for describing points in time, defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1 1970, not counting leap seconds. It is widely used not only on Unix like… … Wikipedia

Unix security — Unix security: maintaining a secure environment on Unix and Unix like operating systems is dependent on design concepts of these operating systems, but vigilance through user and administrative techniques is important to maintain security… … Wikipedia

Unix™ — UK US (also UNIX®) noun [U] TRADEMARK IT ► a powerful computer operating system (= program that controls the way a computer works) that can be used in most types of computers and was important for the development of the internet: »The software is … Financial and business terms

Unix philosophy — The Unix philosophy is a set of cultural norms and philosophical approaches to developing software based on the experience of leading developers of the Unix operating system.McIlroy: A Quarter Century of UnixDoug McIlroy, the inventor of Unix… … Wikipedia

Unix shell — In Unix, a program that acts as a user interface, interpreting commands typed at the keyboard and passing them on to the operating system. The shell sets up standard input, standard output, and standard error, lets you customize your Unix… … Dictionary of networking

Философия UNIX — Философия UNIX это набор культурных норм и философских подходов к разработке программного обеспечения, основанных на опыте ведущих разработчиков операционной системы UNIX. Содержание 1 МакИлрой: Четверть века UNIX 2 Майк Ганцарз: Философия… … Википедия

Shebang (Unix) — In computing, a shebang (also called a hashbang, hashpling, or pound bang) refers to the characters #! when they are the first two characters in a script file. Unix like operating systems take the presence of these two characters as an indication … Wikipedia

Manual page (Unix) — Almost all substantial UNIX and Unix like operating systems have extensive documentation known as man pages (short for manual pages ). The Unix command used to display them is man. Each page is a self contained document. The man command is… … Wikipedia

Источник

Заметки программистера

Страницы

Что такое Unix way?

Что такое «unix way»? Что кроется за этим словосочетанием? Почему идеология, рожденная десятилетия назад, до сих пор является актуальной и позволяет старикам юниксоидам козырять ей перед «оконным» молодняком? Эти вопросы беспокоили меня с первых дней моего знакомства с Linux. Пришла пора поделиться найденными ответами.

История UNIX

..все началось в 1969 году, когда в недрах компании AT&T. Силами ее подразделения Bell Labs была разработана первая UNIX система. Во главе сотрудников исследовательской группы Bell стояли Кен Томпсон (Ken Tompson) и Деннис Ритчи (Dennis Ritchie).

Интересны факт, первое название системы было UNICS (UNiplexed Information and Computing Service). Этот вариант был предложен сотрудником компании AT&T Брайаном Керниганом, и, уже несколько позднее, система обрела свое знаменитое и судьбоносное название UNIX.

Одним из важнейших результатов разработки UNIX можно смело назвать рождение бессмертного языка C. Дело в том, что первые версии системы писались на ассемблере, что, вместе с высокой производительностью, вносило некоторые ограничения в переносимость системы. Решение Томпсона переписать все на языке высоко уровня и привело к появлению нового языка, прародителем которого был язык BCPL. Теперь, для портирования системы на новую архитектуру, достаточно было написать для нее компилятор языка C.

Философия UNIX

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

Потоки ввода/вывода и каналы.

Не смотря на огромное количество красивых заявлений в принципах философии UNIX, наиболее распространенное представление о UNIX way строится вокруг конвейеров.

Это называется каналом(англ. pipe). Каналы позволяют с легкостью объединять программы в конвейеры и добиваться удивительных результатов.

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

Итоги

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

Источник

Unix way

Содержание

МакИлрой: Четверть века UNIX

Дуг МакИлрой, изобретатель каналов UNIX и один из основателей традиции UNIX, обобщил философию следующим образом:

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

Обычно эти высказывания сводятся к одному «Делайте одну вещь, но делайте её хорошо».

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

Пайк: Стиль программирования на C

Роб Пайк (англ. Rob Pike ) предложил следующие «правила» в качестве аксиом программирования. [1] Одновременно эти правила могут выражать точку зрения на философию UNIX:

Первое и второе правила Пайка перефразированы Тони Хоаром (англ. Tony Hoare ) в известную аксиому «Преждевременная оптимизация — корень всех зол». Кен Томпсон (англ. Ken Thompson ) перефразировал 3 и 4 правила Пайка так: «Если сомневаетесь, используйте перебор всех возможных комбинаций». Правила 3 и 4 являются частными положениями философии дизайна KISS: Keep It Simple, Stupid (будь попроще, тупица). Правило 5 было предварительно сформулировано Фредом Бруксом (англ. Fred Brooks ) в книге «Мифический человеко-месяц». Правило 5 часто сокращают до «пиши тупой код, который использует умные данные». Правило 6 взято из шутки Брюса, прозвучавшей в «Летающем цирке Монти Пайтона».

Майк Ганцарз: Философия UNIX

В 1994 году Майк Ганцарз (англ. Mike Gancarz ) объединил свой опыт работы в UNIX (он является членом команды по разработке системы X Window System) с высказываниями из прений, в которых он участвовал со своими приятелями программистами и людьми из других областей деятельности, так или иначе зависящих от UNIX, для создания Философии UNIX, которая сводится к 9 основным принципам:

Менее важные 10 принципов не снискали всеобщего признания в качестве частей философии UNIX и в некоторых случаях являлись предметом горячих споров (монолитное ядро против микроядра):

Реймонд: Искусство программирования в UNIX

Эрик С. Рэймонд (англ. Eric S. Raymond ) в своей книге «Искусство программирования в UNIX» подытожил философию UNIX как широко используемую инженерную философию «Будь попроще, тупица» (Принцип KISS). Затем он описал, как эта обобщенная философия применима в качестве культурных норм UNIX. И это несмотря на то, что несложно найти несколько нарушений в следующей текущей философии UNIX:

Большинство из этих норм принимается вне сообщества UNIX — даже если это было не так во времена, когда они впервые были применены в UNIX, то впоследствии это стало так. К тому же много правил не являются уникальными или оригинальными для сообщества UNIX. Тем не менее, приверженцы программирования в UNIX склоняются к тому, чтобы принять комбинацию этих идей в качестве основ для стиля UNIX.

Цитаты

Критика

Философия UNIX критиковалась в книге «The UNIX Haters Handsbook», написанной сотрудниками компании Microsoft в начале 1990х годов.

По их мнению, подход UNIX приводит к появлению решений, сделанных наспех, без должного продумывания архитектуры, после чего данные решения канонизируются (enshrined), то есть объявляются вечной классикой. Например, таким решением, по их мнению, являются lock files — временные файлы без содержимого, создаваемые как пометка того факта, что какая-то программа находится в процессе исполнения.

Так, например, ими критиковалась X Window System за отделение в ней движка от политики, что привело к отсутствию в UNIX стандарта на политики управления пользовательским интерфейсом и большим затруднениям при разработке приложений, использующих GUI.

Приводился ряд примеров, показывающих, что некоторые решения, принятые в ОС VMS, Microsoft Windows и Apple Mac OS, значительно превосходят своих аналогов из мира UNIX.

Примечания

См. также

Ссылки

Полезное

Смотреть что такое «Unix way» в других словарях:

UNIX way — Философия UNIX это набор культурных норм и философских подходов к разработке программного обеспечения, основанных на опыте ведущих разработчиков операционной системы Содержание 1 МакИлрой: Четверть века UNIX 2 Пайк: Стиль программирования на C … Википедия

Unix time — Unix time, or POSIX time, is a system for describing points in time, defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1 1970, not counting leap seconds. It is widely used not only on Unix like… … Wikipedia

Unix security — Unix security: maintaining a secure environment on Unix and Unix like operating systems is dependent on design concepts of these operating systems, but vigilance through user and administrative techniques is important to maintain security… … Wikipedia

Unix™ — UK US (also UNIX®) noun [U] TRADEMARK IT ► a powerful computer operating system (= program that controls the way a computer works) that can be used in most types of computers and was important for the development of the internet: »The software is … Financial and business terms

Unix philosophy — The Unix philosophy is a set of cultural norms and philosophical approaches to developing software based on the experience of leading developers of the Unix operating system.McIlroy: A Quarter Century of UnixDoug McIlroy, the inventor of Unix… … Wikipedia

Unix shell — In Unix, a program that acts as a user interface, interpreting commands typed at the keyboard and passing them on to the operating system. The shell sets up standard input, standard output, and standard error, lets you customize your Unix… … Dictionary of networking

Философия UNIX — Философия UNIX это набор культурных норм и философских подходов к разработке программного обеспечения, основанных на опыте ведущих разработчиков операционной системы UNIX. Содержание 1 МакИлрой: Четверть века UNIX 2 Майк Ганцарз: Философия… … Википедия

Shebang (Unix) — In computing, a shebang (also called a hashbang, hashpling, or pound bang) refers to the characters #! when they are the first two characters in a script file. Unix like operating systems take the presence of these two characters as an indication … Wikipedia

Manual page (Unix) — Almost all substantial UNIX and Unix like operating systems have extensive documentation known as man pages (short for manual pages ). The Unix command used to display them is man. Each page is a self contained document. The man command is… … Wikipedia

Источник

Unix way что это

Цель: Познакомить обучаемых с предметом обучения.

Вид занятия: лекция, практическое занятие.

3. Разновидности Юникс. Линукс.

5. Средства просмотра системной информации.

2. Армстронг (мл.) Джеймс. Секреты Unix : 2-е изд.: Пер. с

3. Паркер Тим. Linux 5.2. Энциклопедия пользователя: Пер. с

Остальную часть Unix way мы с Вами будем изучать в течение этого курса. Будьте готовы к изучению не просто новых программ, а новых методов работы на компьютере.

Одна из групп пользователей Unix находилась в калифорнийском университете в Беркли. В 1977 году специалисты этого учебного заведения сделали следующий шаг в истории Unix и приступили к распространению магнитных лент с операционной системой 2 BSD ( Berkeley Software Distribution ). С тех пор было продано 75 копий.

Давайте рассмотрим операционную систему как единый комплекс. Ниже приведен список того, что мы получим, установив ее:

Интерфейсы DOS и Windows :

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

uname, запущенная без параметров, покажет базовое имя системы:

Также она может принимать следующие параметры:

Это не все параметры uname. О справке Linux мы поговорим с вами на 5-м занятии.

Команда free показывает объем памяти и объем ее использования, а также использование swap:

total used free shared buffers cached

Mem: 498916 483332 15584 0 4392 112924

-/+ buffers/cache: 366016 132900

Swap: 1453840 412532 1041308

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

Состояние системы в данный момент, степень ее загруженности и время без перезагрузок показывает команда uptime:

14:24:08 up 1 day, 6:01, 2 users, load average: 0.08, 0.19, 0.16

Источник

Как Unix-way убивает десктопный Linux

Нет, конечно же, не убивает.
То, что мертво, умереть не может: доля линукса на десктопах колеблется около 2% уже много лет, и не имеет тенденций ни к росту, ни к падению, изменяясь на уровне статистической погрешности.

Так что да, учитывая долю в 2%, которая не растет, но и не падает, все-таки «не дает вырасти», а не «убивает».

Автор не претендует на абсолютную правильность выводов и суждений, приведенная идея — скорее, затравка для дискуссии, а не всеобьясняющая концепция.

Автор предостерегает от спора с позиции «а у меня такая же нога и ничего не болит», и напоминает, что личный пример не служит доказательством. У вас нога не болит, у меня болит: мы тут в равных условиях. Но я потрудился подвести хоть сколько-нибудь логическую базу к моим тезисам, потрудитесь и вы спорить не с конкретными примерами (на каждый из них можно найти или придумать контрпример и рассказать, почему так), а с идеями. Примеры всего лишь иллюстрируют идеи.

Под «Десктопным Linux» автор имеет ввиду GNU/Linux-based дистрибутивы (Ubuntu, Debian, etc), установленные на обычном x86/x64 компьютере/ноутбуке, с GUI и используемые для бытовых или рабочих целей. Туда не входят такие системы как (даже если они используют ядро linux и его окружение):

1)Android и Chrome OS: несмотря на ядро, это не Linux в той мере, в какой мы его понимаем как продукт: там своя оболочка, свои настройки, свои интерфейсы, свои API для программных продуктов и так далее. Это не линукс, так же как и MacOS это не BSD.

2)Cпецифичные встраиваемые системы, тонкие клиенты, планшеты, умные телевизоры, умные приставки: хоть планшет и телевизор можно с натяжкой назвать десктопом, если подключить к нему клавиатуру, у всех этих систем, как правило, невозможно выбрать ОС по своему вкусу. Что производитель поставил, то и используется.

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

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

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

Причины этой ситуации, как ни странно, те же, что сыграли роль в популярности Linux на серверах: unix-way, «Философия Unix»: «Пишите программы, которые делают что-то одно, и делают это хорошо, и имеют возможность получать и принимать данные через текстовый интерфейс (потому что он универсален)».

Это очень хорошее решение, когда у вас нет:

Быстрого постоянного интернета

Высокоуровневых простых языков типа Python

Кучи фреймворков и библиотек для этих языков в легком доступе

Но есть желание делать свою работу, компьютер и ОС с базовыми инструментами (т.е. ситуация 90-х или 2000-х). Если вы специалист, который может понять некоторые абстрактные концепции, готов писать скрипты-связки, и не требует кнопочки «сделать все хорошо.

Базовое окружение хорошего качества, которое можно комбинировать как угодно, универсальное, бесплатное, переносимое и дописываемое (если уж совсем не хватает фичи или обнаружен баг) — это серьезный шаг по сравнению с поставкой первых ЭВМ, где зачастую-то компилятора нормального не было, или с другими ОС того времени, где приходилось пользоваться, чем дают, да еще и платить за это деньги.

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

Сейчас, когда код программы — это десятки мегабайт текста (и далеко не все из него непосредственно код, там может быть 2мб XML-а) и огромное количество библиотек, когда сборка — отдельное приключение, когда кодовая база пишется десятком человек, ни один обычный пользователь не будет в здравом уме просматривать весь код или пытаться исправить ошибку в чем-нибудь, типа OpenOffice, GIMP-а, KDE или Chrome.
Все исходники прочитать очень сложно, а вероятность найти там ошибку или закладку, просто просматривая код, стремится к нулю: простые места проверили до вас, а в сложных способны разобраться только профессионалы и авторы статических анализаторов :).
Поиск места, в котором засел баг, который вам мешает (даже если вы можете его воспроизвести), если вы обычный пользователь — гиблое дело: отладка больших программ со зрелой кодовой базой (читай «легаси») это отдельное занятие, которому надо учиться, и даже в чем-то искусство.

Произошло это потому, что за 30-50 лет ситуация изменилась. Железо стало более доступным, возникло такое понятие как десктоп, он же «персональный компьютер», и за ними начали массово работать обычные люди, не являющиеся специалистами ни в IT, ни в программировании.

И в этой новой ситуации, достоинство Linux начинает превращаться в недостаток

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

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

Проблема лежит не в плоскости разработки, а в плоскости менеджмента

Процесс развития IT-отрасли не просто привлекает новых пользователей. Он привлекает неподготовленных пользователей. Те рассказы о том, как технарь слету разбирается в интерфейсе телевизора, и на вопрос «ой, у вас наверное дома такой же» отвечает «нет, я его впервые вижу» — это не демонстрация высокого интеллекта этого технаря, это демонстрация знания принципов, по которым строятся почти все интерфейсы. Когда за десяток последних лет вы используете интерфейсы iOS, Android, Symbian, Windows, Linux, двух фотоаппаратов, трех телевизоров, кассетного магнитофона с программируемой записью, факса, копировального аппарата, настенного пульта для кондиционера, MP3-плеера и vi, то у вас появляется насмотренность — вы знаете, как спроектированы большинство в мире интерфейсов, хоть и не можете формализовать это знание в виде четких инструкций, но можете использовать. Например, быстро найти нужный пункт в меню, которое видите впервые.

Но те пользователи, которые приходят в IT сейчас — у них всего этого нет.
У них нет необходимости придумывать пути решения задач — большая часть их работы превращается из творческой в алгоритмическую, когда специалиста учат цепочкам действий, необходимым для работы, а не умению создавать эти цепочки. Потому что дешевле, быстрее, и тоже вполне работает.
У них нет желания и необходимости сортировать файлы по папкам: для них уже сделано облако, отдельное для каждого приложения. И там зачастую не файлы, а абстрактные «проекты».
У них нет страха потери всего: их данные хранятся не на их жестком, и это не совсем их данные, будем честны.
У них нет необходимости разбираться с десятком интерфейсов, они могут вырасти до сознательного возраста, не видя интерфейса кроме айфона и десятка приложений на нем для настройки кондиционера, светильника и вибратора.
Именно для них создаются такие интерфейсы, как, например, Fluent (ribbon) в MS Office: он непривычный, и возможно, менее удобный для тех, кто привык к старому меню, и умеет им пользоваться, но он определенно снижает порог входа для тех, кто еще не умеет.

Время, когда отраслью безраздельно владели гики, закончилось

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

Для того, чтобы они могли пользоваться вашим продуктом, вам необходимо понять, как мыслит ваш средний пользователь, придумать и протестировать интерфейс, функциональность, фичи и пользовательские пути так, чтобы пользователю было как можно более удобно (или, если переформулировать, чтобы покрыть максимальное количество пользователей: на достаточно больших числах это одно и то же).
Этот процесс начался не сейчас, и даже не десять лет назад: уже в 1992 году (почти 30 лет назад!) в Microsoft были специальные отделы, которые проектировали интерфейсы новой системы. И не просто проектировали, а проводили, как сейчас модно это называть, кастдев — интервью с живыми пользователями с проверкой гипотез на прототипах.
Сейчас фокус исследований сместился с того, как именно пользователь будет взаимодействовать с интерфейсом на то, каким путем он будет решать свои проблемы: базовые элементы интерфейса известны, нарисованы в дизайн-гайдах, SDK, фреймворках, и что гораздо более важно, уже запомнены пользователями, поэтому придумывать их не надо, а изменять следует только если у вас есть веская причина.

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

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

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

Именно интересы разработчиков, которые ставятся выше интересов пользователей — это и есть бич Linux

Происходит это потому, что линукс разрабатывается и поддерживается разработчиками, а прочие роли (продакты, аналитики, маркетологи, дизайнеры, UI/UX, редакторы) там присутствуют только по случайности, если они каким-то образом оказались в одном человеке с этим разработчиком (или партнером этого человека).

В традиционной разработке пользовательского ПО, где так или иначе присутствует бизнес, есть четкое понимание, что пользователь = деньги. Возможно не сейчас, возможно в будущем, возможно, он заплатит не напрямую через подписку или покупку, а через рекламу, или вообще деньги придут от инвестора (но будут рассчитаны из количества потенциально-платежных пользователей). В корпоративной (B2B, B2B2C, B2G) разработке может быть по-другому, и деньги могут формироваться даже из того, настолько хорошо ваш продажник дружит с ЛПР другой компании, но в коммерческой B2C разработке деньги приносит пользователь, и удовлетворенность ЦА пользователей это то, что конвертируется в размер аудитории, а значит и в деньги.

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

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

Примеры? Да сколько угодно.

Проблема #1: отсутствие изоляции программ

Традиционный Linux-путь (ну, точнее, *nix-путь) — это хранение настроек и данных в домашней папке пользователя (отличный задел), а библиотек программы — размазанных тонким слоем по системе. Так сложилось исторически, потому что *nix системы представляли собой многопользовательские системы, запущенные на едином «сервере», к которым пользователи подключались с помощью «тонких клиентов» (очень тонких) — в минимальном варианте это был принтер и клавиатура, что и определило текстово-консольный интерфейс как основной, заложив основы того, что позволило Linux занять свое текущее положение на серверах. Со временем «очень тонкий клиент» превратился в монитор, к которому подключался либо знакогенератор, либо упрощенный компьютер. Это, в свою очередь, привело к тому, что графический интерфейс оказался разделен на серверную и клиентскую части, что доставило (и продолжает доставлять) немало проблем в условиях, когда в таком разделении нужда отпала. Из-за множества пользователей логичным решением было экономить место на жестком диске, жестко отделяя исполняемые файлы от данных, и как логичный следующий шаг — экономить место среди исполняемых файлов, разделяя выделенную логику конкретного приложения и библиотеки, которые могут использоваться не только этим приложением. Это почти не давало выигрыша в ранних однопользовательских системах (все равно приходилось хранить как минимум одну копию исполняемых файлов и библиотек к ним), но ощутимо экономило место для многопользовательских систем.

Но в современном мире ситуация изменилась.
Во-первых, резко возросло количество библиотек, пакетов, и их зависимостей, вырос темп разработки, а место на жестком диске очень сильно упало в цене.
Во-вторых, современные системы — однопользовательские. Ну, в худшем случае, двух- или трех-пользовательские: стоимость железа такова, что не проблема купить каждому пользователю по компьютеру или даже по высокопроизводительной рабочей станции (она все равно не будет стоить больше пары зарплат специалиста). А если ресурсов ее не хватит — с развитием интернета к вашим услугам огромное количество облачных серверов: стоимость и развитие аппаратных ресурсов, позволяет переносить многопользовательность в область виртуальных машин: накладные расходы на это небольшие, их с лихвой окупает изоляция и возможность кастомизации каждой виртуальной машины.
В тех применениях, где присутствует все-таки множество пользователей (например, в веб-сервисах), их количество настолько большое, а спектр запросов настолько мал (я имею ввиду функциональность одного сервиса по сравнению со всеми комбинациями инструментов в *nix), что нет никакого смысла отдавать им настоящую системную многопользовательность со всеми ее возможностями и недостатками, гораздо проще написать свою, маленькую и карманную, сделав это выше системного уровня, на пользовательском уровне ОС: когда база данных одна, логика приложения одна, веб-сервер один, все это работает от одного или от 2-3 пользователей ОС, но внутри они разделяют между собой тысячи аккаунтов клиентов.

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

Однако, софт в Linux до сих пор использует концепцию разделяемых библиотек, отчасти «потому что так сложилось», отчасти по причине плюсов, связанных с безопасностью: ошибка, допущенная в ssl-библиотеке может создать уязвимость в десятке приложений, ее использующих. В случае разделяемых библиотек достаточно будет обновить пакет библиотеки, и при условии неизменности ABI библиотеки, все остальные приложения сразу же исправят уязвимость без каких-либо действий авторов и мейнтейнеров.

Альтернатива — это пакетирование программ в самодостаточные сборки, со всеми (или большинством) зависимостей. Вариантов много — Application Bundles / AppImage / Snappy (Ubuntu) / Flatpack (Gnome), но они тоже имеют недостатки и критику.

Однако и текущая реализация механизма разделяемых библиотек и установки пакетов с зависимостями — это далеко не совершенная конструкция, которая на задачах чуть сложнее стандартных легко скатывается в dependency hell, что тут же на порядок повышает сложность обслуживания системы: там где в Windows надо просто переустановить программу, в Linux приходится ковыряться в глубине пакетного менеджера. Причем получить ситуацию ада зависимостей можно достаточно легко — при попытке поставить новую версию ПО, которая требует новой версии библиотеки, которая несовместима с существующим ПО, погуглить, как установить вторую версию библиотеки, ввести пару команд с SO. Все, apt-get невнятно ругается, не предлагая никаких осмысленных действий. В связи с отсутствием механизма миграции (см. следующий пункт) альтернатива «снести все и поставить заново» превращается в долгий и нудный перенос данных и настроек — тоже плохой вариант.

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

В качестве рабочего примера можно посмотреть на Docker. Так как он работает в сегменте серверного Linux, то там есть интересы бизнеса (в стоимости ресурсов, поддержки, обновлений, обслуживания, раскатки и т.д.), который видит решение проблемы и из-за этого голосуют за использование и разработку докера, даже несмотря на ощутимый оверхед по ресурсам.
Это происходит из-за того, что основной плюс докера вовсе не в быстрой раскатке и обновлении приложений — этого можно было бы добиться и с Ansible, например.
Сила докера — в самодостаточности образа (все нужное окружение он несет в себе, и при правильном проектировании образа есть хорошая гарантия, что он запустится где угодно) и принудительности хранения данных и настроек отдельно от кода (так как образы докера эфемерны и легко удаляются и создаются заново при обновлении или новом деплое, и для юзера, де-факто, неизменны, а значит, заставляют хранить данные в другом месте).

Всем этим докер сводит логический модуль к черному ящику: дай ему ресурсы (память, хранилище, процессор, сеть), укажи место хранения настроек и данных через унифицированный механизм ФС (хоть что-то у нас есть унифицированного), и дальше он будет работать сам. Сломался код? Надо мигрировать на новую версию? Образ убивается, собирается новый, запускается с теми же параметрами, и опа, все работает как и прежде.
Я говорю о логических модулях, потому что изолируются именно куски логики (бизнес-логики, если угодно), а не отдельные программы: контейнер может включать в себя, например, два сервиса на разных языках программирования (или на языках разных версий), сами языки программирования, их зависимости и библиотеки, логику обслуживания при падении, централизованный клиент сбора логов, мониторинг, локальную временную БД, и так далее. И у десяти разных контейнеров это не размазывается тонким слоем по системе, начиная интерферировать друг с другом, а работает изолированно и обособленно друг от друга, непринужденно убивается, сносится и ставится заново, никак не ломая хост-систему и друг друга.
И именно поэтому, несмотря на ситуацию, когда образ с единицей логики в 5мб весит 500мб, потому что тащит за собой копию потрохов системы, такая концепция настолько упрощает работу, что «на ура» принимается бизнесом.

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

Проблема #2: сложность миграции с версии на версию

Во время многопользовательности линукса настройки были разделены на два места: настройки пользовательских программ и настройки общесистемных программ. Пользовательские настройки лежали в /home/user/.config, а системные, которые применяются к программам, запущенным не от пользователя или используемыми всеми пользователями — в /etc.

Но в процессе превращения в де-факто однопользовательскую систему эта стройная логика была разрушена.
Например, xorg/x11 — в текущей реальности это программа пользовательского уровня: настройки в ней настраивают конкретную видеокарту и конкретный монитор пользователя. Второй может пользоваться консолью, третий ходить исключительно по ssh. Но файл настроек лежит в /etc (и хорошо если не в /usr/share/X11), и он одинаков для всех.
apt-get — тоже программа пользовательского уровня. У каждого пользователя могут быть свои репозитории, и негоже пытаться установить python-4-alpha-dev всем пользователям только потому, что для одного из них это обычная среда. Но конфиги и репозитории лежат в /etc. apt-get, кстати, запускается тоже только от root.
Ладно, фиг с ними, с репозиториями. Но вот список установленного софта — уж точно пользовательская штука, правда? Я на каждый компьютер ставлю определенный список программ, и если уж у нас есть рабочая система с репозиториями, которая снимает необходимость качать и ставить софт вручную, давайте же упростим задачу установки любимых программ на новую систему. Как мне получить список установленных мной пакетов. Никак. Не существует нормального механизма, который бы показал, что именно вы устанавливали (есть вот такие неофициальные решения, которые могут сломаться в любой момент), и не предполагается никакого метода хранения этого списка вместе с пользовательскими настройками.
Ладно установленные программы, раз они шарятся между юзерами, то может и правда логичнее ставить их всем, не разбираясь. Но вот запускаемые программы-то — это собственность пользователя, правда же? Ну, я поставил мускуль, коллега постгри. Каждый из-под своего аккаунта. При старте запустятся оба, если не сделать сложных телодвижений по поводу запуска из скриптов оболочки. Какая там многопользовательность, о чем вы. Я понимаю, что на это есть причины, и даже знаю, какие. Но эти причины не отменяют то, что список программ, которые при запуске нужны мне, как конкретному юзеру, лежат в /etc.

Что у нас там еще из пользовательских программ? reboot. Пользователь же может перезагрузить компьютер, правда? Это же его компьютер? Нет, не может? Нужен root? Блин.
openvpn, ppp — тоже же пользовательские штуки. Зачем другому пользователю мой корпоративный vpn и зачем для его добавления себе нужен root? Но лежат в /etc.

Ладно. Как я уже говорил, я установил себе БД для работы. База запускается от своего пользователя, mysql:mysql какой-нибудь. Настройки лежат. Наверное в /home/mysql/.config/mysql? Нет не угадали. Тоже в /etc! Почему? А вот. Ладно. БД хранит данные где-то на диске. Где они хранятся, в /home/mysql/data? Нет. В /var/lib/mysql. Ну йооооханный.
Особенно весело, когда вам и вашему коллеге надо будет поставить две одинаковых БД с чуть разной версией. Опытный админ пошлет вас на х.. запускать виртуалку или ставить в докер, и будет прав.

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

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

Что в итоге? А в итоге, миграция на новую систему — адский геморрой: скопировать свою папку недостаточно, часть файлов надо вытащить из /etc, но все копировать нельзя, потому что это сломает новую инсталляцию, часть файлов собрать по системе, никогда не знаешь, на что наткнешься в следующий раз, список пакетов получаешь с трудом (о существовании возможности это сделать кроме как через history|grep install я узнал только при написании этой статьи, хотя опыта с линуксами с полтора десятка лет).

Несмотря на то, что официальный способ конфигурирования — через текстовые конфиги, никто не реализовал способ сравнения конфигов (неважно, через diff или через layers ФС), чтобы иметь хотя бы представление «а что я там в конфиге в прошлый раз правил», чтобы отделить свои правки от системного стока. Вот в гите такое есть, потому что это требование бизнеса в виде разработки, а в ОС.. И так норм, мы привыкли.

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

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

Десктопный линукс. десктопный линукс сидит и ест клей.

Проблема #3: отсутствие единого конфигуратора

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

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

И такое — с почти всеми нетривиальными настройками системы. Разрешение монитора не определяется нормально? Добро пожаловать в волшебный мир конфигурационных файлов иксов (или wayland, если вам «повезло». Повезло в кавычках — потому что документов по конфигурированию wayland-а еще меньше). Хотите повернуть экран? Выбирайте:

Ну, вы поняли. В зависимости от того, хотите вы повернуть экран вообще, на уровне драйвера HDMI, или немножко, на уровне иксов, хотите вы его переворачивать в процессе работы или один раз, в зависимости от того, в какой из портов на видеокарте у вас подключен монитор, в зависимости от того, ноутбук у вас или десктоп, в зависимости от того, малина у вас или x86, в зависимости от того, NVIDIA/AMD/Intel у вас видеокарта, вам нужны разные команды.

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

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

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

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

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

Проблема #4: рассинхронизация интерфейсов общения с пользователем

У Windows это есть, хоть иногда и встречается невнятное «Память не может быть read» и «Error 0x000000F2DA563333».
У MacOS это реализовано хуже: ошибки в программе скорее всего выведутся, а вот некоторые программы могут падать при запуске, ничего не говоря
В Linux нормальна ситуация, когда ты нажимаешь кнопку в интерфейсе, она не нажимается, и ничего не говорит. И только в консольном выводе можно увидеть ошибку библиотеки фреймворка, которая говорит, что undefined какой-то аргумент объекта кнопки.
В итоге, даже просто желание погуглить ошибку при работе GUI программы зачастую превращается в увлекательный квест. С консольными программами тоже есть приколы — в целом, пользователь не знает, куда складывает лог конкретная программа: это может быть свой лог в соседнем файлике или текущей папке, это может быть /var/log/program_name, это может быть какой-то общесистемный журнал или журнал конкретного метода автозапуска программы.

Проблема #5: непроработанность функциональности ПО и неконсистентность инструментов

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

О том, как пользователь пользуется всей программой в целом — не задумываются. Условно, если мы сначала копируем один обьект, а потом в 99% его вставляем рядом, хорошо бы не закрывать меню с кнопками «копировать» и «вставить», это меньше движения курсора, меньше кликов. А еще хорошо бы сделать кнопку «дублировать». Это самый простой синтетический пример.
Реальные проблемы сложнее и включают в себя множество действий, которые часто выполнятся друг за другом в рамках одной пользовательской сессии, и которые хорошо бы сворачивать для упрощения работы. Или действия, которые выполняются наоборот, очень редко, и каждый раз вызывают недоумение у пользователя, потому что он успевает забыть, как именно это делается. Такие действия наоборот, можно разбивать на несколько более простых шагов, чтобы упростить пользовательский путь: логическую цепочку запомнить проще, чем магическую кнопку, спрятанную в недрах меню. А если она не спрятана в меню — все еще хуже, потому что ненужные и неиспользуемые функции загромождают меню, и не дают вынести в него то, что нужно на самом деле.

Но для этого надо понять, что именно делают пользователи, и как они это делают. У разработчика может не быть проблем — он, в конце-концов, сам проектировал этот интерфейс, и он точно сделан идеально под него. У опытных пользователей тоже может не быть проблем: они уже привыкли и ощущение «блин, ничерта непонятно» у них уже давно в прошлом (как пользователь Blender и Eagle заявляю, что привыкнуть можно к любому интерфейсу, если пользуешься им достаточно часто).

И вот тут опять же, провал: проблемами пользователя никто не занимается. Можно сравнить GIMP и Photoshop, Inkscape и Illustrator: базовый функционал у них действительно похож. Но покажите обе программы начинающему пользователю, и будет понятно, в чем разница.

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

Итоги

Все описанное выше — это не какие-то недоработки, которые можно взять и исправить, или страдания миллениалов, не могущих освоить не очень сложный интерфейс (а ваши деды в микрокодах писали!).
Это системные прое.. проблемы в архитектурной части, для исправления которых нужны значительные ресурсы не только в части времени и денег, но и запас проектной диктатуры, и смелости ломать уже существующие пользовательские привычки. Ведь, поправив все это — линукс уже не будет той системой, к которой привыкли эти миллионы людей, составляющие два процента. Лично для них миграция будет более болезненной и неприятной, чем освоение новой системы новичком.
К тому же проектной диктатуры в Opensource не хватает, потому что система построена на интересе. Уменьши интерес от запиливания новых фич, сказав «нам надо заниматься рефакторингом и слушать вот этого чувака-продакта безоговорочно» и разработчик пойдет коммитить в другой, более лояльный к интересам разработчика проект.

У меня нет плана, как это все исправить. Деньги — не настолько большая проблема, как кажется: они есть у государства, например. Правительство вполне понимает риски завязывания всей IT-структуры страны на чужое ПО и может выделить деньги в рамках программы импортозамещения, например. Гораздо важнее, как построить структуру так, чтобы эти деньги пошли именно на продуктовую разработку: как я уже говорил, для этого необходимо сделать метрикой успешности удовлетворенность пользователя.
Но, выделяя деньги на «российский линукс» абстрактно, это сделать невозможно: если государству нужен российский линукс, у него будет российский линукс, а про качество продукта там ничего не сказано.
Если выделить деньги госучреждениям с тезисом «закупайте сами», они закупят привычный Windows.
Если сказать «закупайте что угодно, кроме Windows», закупят ту систему, которая откатит больше бонусов: выбирать из десятка систем сложно, потому что они все одинаково кривые.
Если так и поставить задачу «сделайте линукс, которым удобно пользоваться», то сделают линукс, которым будет удобно пользоваться по мнению экспертной комиссии, а не по мнению пользователей: без свободного рынка оценить удобство можно только экспертно, а вот критерии экспертности уже формализуются настолько сложно, что никто этим заморачиваться не будет (или будет, что еще хуже).

Но если все пойдет, как идет сейчас, то Linux как Desktop-система продержится еще 5-10 лет, вряд ли больше: Microsoft осознает свою проблему в отсутствии POSIX-совместимости и невозможности работать со всеми теми наработками в OpenSource, созданными за 20 лет, и активно впиливает поддержку, используя ядро Linux внутри своей системы. Через некоторое время интеграция станет настолько хорошей, а инструменты вроде терминала разовьются достаточно, чтобы те, кто работал на Linux из-за удобства разработки, отладки и запуска серверных решений, перешли на винду: разницы нет, а интерфейс и удобство на порядок выше. И тогда десктопный линукс останется уделом полупроцента фриков и параноиков, из-за чего любая разработка заглохнет окончательно.

Источник