Не знаю, насколько это адеквано, но вот, что по этому поводу думаю:
1. Хоть на сегодняшний день ядро уже супер крутое и стабильное, изначально выбор концепции монолитного ядра был ошибочен, все равно пришлось делать подгружаемые модули чтобы каждый раз не "компилить ядро" под новое устройство
Насколько помнится, оно вообще было сделано just for fun и вряд-ли было таким огромным, как сейчас. В наше время подгружаем модули и проблемы больше нет. А вообще спор Торвальдса и Таненбаума - тема отдельной спецолимпиады.
2. Хоть система и супер всеядна под любые файловые системы, файло ориентированная концепция внутри ядра не сильно оправдалась, это было актуально на мейнфреймах того времени но не на ПК)))
Не понял, почему.
3. Структура файловой системы когда все приложения тонким слоем размазаны по каталогом и подкаталогам самой системы дико усложняет процесс инсталляции/деинсталляции различных приложений. Вот сидела бы сама система скромненько в отдельной папке, а всё остальное в тех папках которые укажет "юзверь" )))))))
Скорее проблема в куче дистрибутивов, которые тулят приложения в /usr/local, например. Дико бесит. С puppy та же хрень.
А так админу удобно - понятно, где приложения, либы, доки, пикчи, переводы, бинарники, настройки (попробуй в виндах найти все это, особенно настройки - лазим в program files, program data в корне c:, windows и куча подпапок, user/appdata/local, user/appdata/locallow/, user/appdata/roaming, documets и/или в папке программы, также шерстим реестр), а "юзвергу" вообще выше своего каталога лазить нечего и сидеть ЮЗЕРУ скромненько там.
Ничего не знает - дольше проживет и его нервная система и система операционная.
4. Концепция выбора точки монтирования, а затем процесс монтирования/размонтирования дисков, на десктопах сломало психику не малому количеству энтузиастов)))
Тоже ничего не понял. Наверное это энтузиасты без энтузиазма просто.
5. Куча всяких зависимостей временами так хитросплетенных между собой )))) Это раньше экономило свободное место на диске, но это уже не актуально со времен первых пентиумов)))
Частично согласен. Но уже не так актуально с развитием ПМ (если не компилить из исходников, конечно же). В винде вроде как зависимостей меньше, но это на первый взгляд. Чего стоит dotnet и visual C, direct... Плюс куча обновлений и исправлений к ним. Ставим игрушку или прогу - в нагрузку еще получаем opengl-ы, openal-ы, sdl-ы, python-ы и еще черт знает чего, чего мы никогда не узнаем - списки установленного смотреть негде, плюс реестр опять таки; эта вся чехня действительно может быть размазана по всей ФС в самых неожиданных местах и так же как в линухе, может чего-то сломать.
Сюда же дубли одних и тех же либ. Установка не в program files создает лютый бардак на винте и в голове, в подходе и отношении. В линухе тоже можно такой срач сделать appimage-ами и docker-ами.
6. Отречение от бинарной совместимости дистрибутивов хотя бы на платформе x86 отпугнуло огромную массу идейных и талантливых программистов от реализации своих идей под Linux, ибо знать тонкости разных версий дистрибутивов уже подвиг на который не многие способны, не говоря уже о дистрибутивах разных сообществ)))))
Согласен.
7. И почему Массово на системе вдоль и поперек написанной на Си, командная строка реализована в стиле хрен знает чего 
Почему Bash , а не Си подобные командные оболочки, они ведь тоже существуют !?!?))))))
Потому, что вообще никто не пользовался бы, особенно если компилить каждый хоть даже маленький сценарий после каждой правки)
(загнул конечно, мы же про интерпретаторы)
Bash ведь просто сценарий для обмена потоками между мелкими утилитами и не надо тут городить огород. Ему бы только добавить нормальную работу с массивами - большего и не надо. Это не ЯП.
CMD вот всех устраивает) Может задать вопрос мелкомягким - "почему на системе вдоль и поперек написанной на C#, не С#-подобная оболочка?"
Сайт
Скачать
Видео
Wiki
