Ну, как ни крути, без оценки не обойтись. Оценка нужна, что бы понимать что к чему и почему на самом деле. Причём в моей оценке нет унижений и оскорблений, просто констатация фактов, как они есть.
1. Пользователю не запрещается, но подключение стороннего репозитория или установка сторонней deb-ки, может поломать систему, причём так, что откатить изменения совсем не просто, придётся попотеть, а обычному юзеру без продвинутых скиллов по администрированию линукса — проблема вообще не разрешима. Сам не раз боролся с системой deb-пакетов по данному поводу — удовольствие не из приятных (
2. Иногда пользователю совершенно наплевать на всю операционную систему и всех мейнтейнеров дистрибутива, обеспечивающих «рабочую систему», если он не может запустить софт, ради которого он вообще купил компьютер. Для него это уже нерабочая система. Грустно, но факт, что сложность возни с установкой софта под линуксы — одно из главных препятствий для его распространения как основной ОС у обычных пользователей. Да, не возникает проблем с установкой софта, который уже есть в официальном репозитории, но в 90%-100% случаев пользователю нужно ещё что-то, чего в репозитории нет. Да и производителям софта, подстраиваться под весь этот зоопарк совсем не хочется, и их можно понять.
3. В данном случае речь идёт только об основе операционной системы вообще, на самых низах, т.е. об экосистеме C-программ. Другие экосистемы более высокого уровня, такие как erlang, python, ruby, node, java и т.д., могут решать свои проблемы так как им интересно. Хотя проблема зависимостей она вообще то общая и у всех одинаковая. И здесь лишь вопрос о возможности прийти к консенсусу, если говорить о всеобщем принятии стандарта управления зависимостями. Но, я думаю если основа, которая состоит из C-программ, сможет сформировать подход, который докажет свою работоспособность и эффективность, то другие экосистемы наверняка начнут перенимать этот или очень похожий подход. Хотя как раз экосистема C-программ, так уж сложилось исторически — наиболее разрозненная, к сожалению.
А в общем да, вы правы, проблема в человеческой психологии, и эголитарном анархизме как её проявлении. Не доросло ещё человечество на данной планете до осознания общего блага и его ценности. Но это тема для уже совсем другого разговора.
А разве соблюдение непротиворечивости репозиториев дистрибутивов мейнтейнерами не есть задача очень высокой трудоёмкости? Разве это приемлемо, когда пользователю запрещается использовать более свежее ПО, а авторам программ для обхода этого запрета приходится идти по пути windows, когда любое ПО — это гигабайты и гигабайты дистрибутивов, десятки гигабайт впустую занимаются на диске, только из-за того, что каждая программа тащит с собой всё своё обособленное дерево зависимостей? Но плачут, колются, но продолжают есть кактус, просто потому что и так худо-бедно, но работает. И ни кто в общем то не стремится решать этот вопрос раз и на всегда. А поскольку проблема фундаментальна по своей природе, то и решать её нужно не спеша и основательно.
На мой взгляд здесь нет ни чего неразрешимого — достаточно один раз инвестировать усилия в реформу системы создания ПО, и потом будет очень не малый профит. А за обеспечение устойчивости, что бы ни чего не поломалось, должны отвечать беспристрастные, точные и выверенные автоматические инструменты, которые будут постоянно мониторить и тестировать репозитории, и не допускать в репозитории ПО дистрибутивов пакеты, ломающие существующие зависимости. DevOps и автоматизация рутинных задач рулит.
Но мешает данному прогрессу закостенелость устоявшейся системы разработки ПО, нежелание библиотек-старожилов реформироваться, и не желание всего сообщества пересматривать и менять подходы к своей работе, а для этих реформ нужна всеобщая кооперация, которая должна начинаться как раз с основ — с титанов держащих на своих плечах все дистрибутивы — с основных общесистемных библиотек и программ, вроде glibc и того же линкера, обеспечивающего запуск программ. А они то как раз более всего сопротивляются каким либо серьёзным изменениям.
Такие старые и уже устоявшиеся библиотеки как openssl с очень редко меняющимся ABI, могут иметь очень слабо детализированную зависимость от версий, скажем приложения зависят только от major версии библиотеки, тогда вероятность того, что в системе окажется множество разных версий с уязвимостями, очень мала — скорее всего в системе будет только одна, регулярно обновляемая версия. А другие, более активно меняющиеся библиотеки, как например библиотеки графического интерфейса, будут иметь большую детализацию по версии. Ведь привязка зависимостей к версии на прямую зависит от частоты изменений ABI библиотеки — чем реже меняется ABI, тем меньше версий библиотеки в системе нужно.
И кстати, и сейчас, почему вы обновив библиотеку с уязвимостями, перестаёте беспокоиться? Вдруг какое то приложение внутри себя несёт более старую версию библиотеки с уязвимостью и использует её, а не общесистемную.
Это вопрос о детализации версий в списке зависимостей. Если детализация идёт до 2-й цифры версии, скажем libbar зависит от libfoo-0.1.*, то обновления библиотеки libfoo-0.1.1 до версии libfoo-0.1.2 должны строго соблюдать совместимость ABI как отче нашЪ, тогда libbar при загрузке в память процесса слинкуется с libfoo-0.1.2 и даже не заметит разницы. Если же ломается ABI при обновлении, то это уже должна быть версия libfoo-0.2.0, а не libfoo-0.1.2
Если же говорить о dll hell в рамках одного процесса в памяти, то это уже другая, гораздо более сложная проблема, с которой я тоже сталкивался. Можно подумать, что это вина автора приложения, который не проследил консистентность всего дерева зависимостей приложения, но как оказывется, дерево зависимостей приложения может поломаться уже после успешного создания приложения и внедрения его в эксплуатацию: какая то из библиотек, от которых зависит приложение обновилась и изменила свои зависимости на более свежие версии, которые не совместимы с зависимостями самого приложения или других библиотек, от которых зависит приложение.
Именно по этому я ратую за переосмысление вообще всей концепции разделяемых библиотек, от низа до верха. Во первых менеджер пакетов должен нормально и качественно обустраивать сосуществование разных версий библиотеки в системе (то как это делается сейчас путём включения номера версии в имя пакета, явно указывает на костыльность решения), во вторых сама библиотека должна осознавать, что несколько версий её же может присутствовать в системе (и даже более, могут работать в программах одновременно) и должна это учитывать, в третьих ld_linker при запуске программы должен иметь в себе достаточно умный solver зависимостей, который должен уметь выстраивать внутренне не противоречивое дерево зависимостей программы, подбирая версии библиотек так, что бы не было конфликтов, даже за счёт включения более старых версий библиотек в дерево для обеспечения совместимости, иначе программа просто не запустится. Так-же и сам менеджер пакетов должен иметь внутри себя подобный solver зависимостей, для обеспечения присутствия в системе всех нужных для запуска программ библиотек, даже более старых тогда когда это требуется для формирования непротиворечивых деревьев зависимостей во время запуска программ. Ведь dll hell в рамках одной программы это явно не заложенное изначально автором программы состояние, ведь когда он создавал приложение, оно работало и не было ни какого dll hell, который приползает потом, тихо и неожиданно.
Потом уже можно и поразмыслить над возможностью одновременной загрузки разных версий библиотеки в память процесса и о том как этого достичь…
Проблема в некачественных метаданных о библиотеке из апстрима. И именно на исправлении этой проблемы стоит фокусировать усилия — давить на автора библиотеки что бы он поставлял качественные метаданные, возвращать в апстрим исправления метаданных от мейнтейнеров дистрибутивов, вести пропаганду и политику о качественных и своевременно обновляемых метаданных и т.д.
Ведь в мире совместного использования библиотек, качественные метаданные о совместимостях&зависимостях являются неотъемлемым требованием к самой библиотеке и приложению её использующему в режиме must have, и бить по рукам за отсутствие/кривизну метаданных в апстриме.
Но как раз на метаданные все хорошенько так подзабили, считая это не важным делом, а по сему имеем что имеем (
По моим эмпирическим наблюдениям, то как сейчас ведут в дистрибутивах сосуществование разных версий библиотеки — поверхностно и недостаточно. Оно и понятно, поскольку это делается вручную мейнтейнерами дистрибутивов, что очень трудозатратно, неэффективно, не надёжно и долго. Зачастую обновления библиотеки в рамках major версии библиотеки всё равно ломают ABI совместимость, из-за чего дистрибутивы предпочитают привязываться к более конкретной версии библиотеки и по прежнему запрещают обновление. Т.е. мы по прежнему имеем запреты на установку более свежих версий библиотеки. Сам на это не один раз натыкался.
Для полного-же решения данной проблемы необходимо создать инструменты для автоматического управления версиями библиотек в репозиториях дистрибутивов и на инсталляциях дистрибутивов, а детальные метаданные о зависимостях и совместимостях библиотек должны идти с апстрима библиотеки, в виде пригодном для обработки их автоматическими инструментами.
Именно на это нужно вести политику и давить на авторов библиотек, что бы они поставляли точные, детальные и не глючные метаданные, а не создавать всякие snap&flatpack.
Как вы и написали, есть в данной ситуации два экстремума — максимально идеальное общее счастье (коммунизм, минимум свободы пользователю), и максимально жирный дистрибутив и минимум общего счастья (индивидуализм, максимум свободы пользователю).
Как и в экономике, первый вариант приносит максимум эффективности, но подобен золотой клетке и отсутствию свободы, а второй (как и капитализм) вариант приносит минимум общей эффективности, но приносит свободу.
Ни тот ни другой вариант не приемлем для пользователя, а значит нужно искать общий компромисс с максимальным локальным результатом для пользователя. И сосуществование в системе разных версий библиотеки — это как раз такой компромисс. Причём это не отменяет возможности обновлять отдельную версию библиотеки, но эти обновления должны строжайше соблюдать совместимость ABI и вносить в общем случае только security&bug fixes.
Этот вариант — наименьшее зло. И по такому пути пошли разработчики дистрибутива gentoo, они ввели в свой пакетный менеджер понятие слотов, и каждый пакет (теоретически) может быть установлен в системе в нескольких версиях одновременно в разные «слоты». Если у нас на 1000 пакетов будет 30 версий библиотеки (что мало вероятно, скорее всего будет значительно меньше), то это гораздо лучше варианта когда на 1000 пакетов та-же 1000 версий библиотеки. По опыту работы с gentoo могу сказать, что в системе одновременно сосуществует самый максимум 3-5 версий библиотеки, а в общем по системе редко когда больше одной.
Это приведёт к плавному и безболезненному введению в эксплуатацию новых версий библиотеки, и автоматическому удалению из системы старых версий, которые не нужны больше ни одному приложению в системе. Если какое либо приложение надолго застрянет со старой версией библиотеки, то в конечном итоге во всей системе использовать её будет только это приложение, и это проблемы этого приложения, а не всей системы в целом.
Вообще эта ситуация удивительна — на дворе уже давным-давно 21-й век, а эта фундаментальная проблема до сих пор не решена, и похоже не собирается решаться.
Коренная проблема общего счастья здесь одна — это dll hell, из-за которого LTS дистрибутив отказывается принимать новые версии библиотек, а разработчик приложения вынужден тащить с собой свою локальную версию библиотеки.
Но проблема может быть решена под другим углом — нужно поменять парадигму понимания библиотеки, сейчас все понимают библиотеку как одну единую сущность, с которой обязаны линковаться все кто её используют. Для решения проблемы dll hell необходимо принять парадигму, что библиотека — это не одна сущность, а целый набор мало отличающихся друг от друга сущностей (разных версий библиотеки), которые должны без проблем сосуществовать друг с другом в рамках общей системы, а с какой именно версией линковаться — решает каждое отдельное приложение. Это позволит по зависимости легко и без проблем подтянуть в LTS дистрибутив новую нестабильную версию библиотеки, и использовать её будет только то приложение, которому нужна именно эта версия, все же остальные приложения в системе, продолжат использовать стабильную версию, на которую они рассчитаны.
1. Пользователю не запрещается, но подключение стороннего репозитория или установка сторонней deb-ки, может поломать систему, причём так, что откатить изменения совсем не просто, придётся попотеть, а обычному юзеру без продвинутых скиллов по администрированию линукса — проблема вообще не разрешима. Сам не раз боролся с системой deb-пакетов по данному поводу — удовольствие не из приятных (
2. Иногда пользователю совершенно наплевать на всю операционную систему и всех мейнтейнеров дистрибутива, обеспечивающих «рабочую систему», если он не может запустить софт, ради которого он вообще купил компьютер. Для него это уже нерабочая система. Грустно, но факт, что сложность возни с установкой софта под линуксы — одно из главных препятствий для его распространения как основной ОС у обычных пользователей. Да, не возникает проблем с установкой софта, который уже есть в официальном репозитории, но в 90%-100% случаев пользователю нужно ещё что-то, чего в репозитории нет. Да и производителям софта, подстраиваться под весь этот зоопарк совсем не хочется, и их можно понять.
3. В данном случае речь идёт только об основе операционной системы вообще, на самых низах, т.е. об экосистеме C-программ. Другие экосистемы более высокого уровня, такие как erlang, python, ruby, node, java и т.д., могут решать свои проблемы так как им интересно. Хотя проблема зависимостей она вообще то общая и у всех одинаковая. И здесь лишь вопрос о возможности прийти к консенсусу, если говорить о всеобщем принятии стандарта управления зависимостями. Но, я думаю если основа, которая состоит из C-программ, сможет сформировать подход, который докажет свою работоспособность и эффективность, то другие экосистемы наверняка начнут перенимать этот или очень похожий подход. Хотя как раз экосистема C-программ, так уж сложилось исторически — наиболее разрозненная, к сожалению.
А в общем да, вы правы, проблема в человеческой психологии, и эголитарном анархизме как её проявлении. Не доросло ещё человечество на данной планете до осознания общего блага и его ценности. Но это тема для уже совсем другого разговора.
На мой взгляд здесь нет ни чего неразрешимого — достаточно один раз инвестировать усилия в реформу системы создания ПО, и потом будет очень не малый профит. А за обеспечение устойчивости, что бы ни чего не поломалось, должны отвечать беспристрастные, точные и выверенные автоматические инструменты, которые будут постоянно мониторить и тестировать репозитории, и не допускать в репозитории ПО дистрибутивов пакеты, ломающие существующие зависимости. DevOps и автоматизация рутинных задач рулит.
Но мешает данному прогрессу закостенелость устоявшейся системы разработки ПО, нежелание библиотек-старожилов реформироваться, и не желание всего сообщества пересматривать и менять подходы к своей работе, а для этих реформ нужна всеобщая кооперация, которая должна начинаться как раз с основ — с титанов держащих на своих плечах все дистрибутивы — с основных общесистемных библиотек и программ, вроде glibc и того же линкера, обеспечивающего запуск программ. А они то как раз более всего сопротивляются каким либо серьёзным изменениям.
И кстати, и сейчас, почему вы обновив библиотеку с уязвимостями, перестаёте беспокоиться? Вдруг какое то приложение внутри себя несёт более старую версию библиотеки с уязвимостью и использует её, а не общесистемную.
Если же говорить о dll hell в рамках одного процесса в памяти, то это уже другая, гораздо более сложная проблема, с которой я тоже сталкивался. Можно подумать, что это вина автора приложения, который не проследил консистентность всего дерева зависимостей приложения, но как оказывется, дерево зависимостей приложения может поломаться уже после успешного создания приложения и внедрения его в эксплуатацию: какая то из библиотек, от которых зависит приложение обновилась и изменила свои зависимости на более свежие версии, которые не совместимы с зависимостями самого приложения или других библиотек, от которых зависит приложение.
Именно по этому я ратую за переосмысление вообще всей концепции разделяемых библиотек, от низа до верха. Во первых менеджер пакетов должен нормально и качественно обустраивать сосуществование разных версий библиотеки в системе (то как это делается сейчас путём включения номера версии в имя пакета, явно указывает на костыльность решения), во вторых сама библиотека должна осознавать, что несколько версий её же может присутствовать в системе (и даже более, могут работать в программах одновременно) и должна это учитывать, в третьих ld_linker при запуске программы должен иметь в себе достаточно умный solver зависимостей, который должен уметь выстраивать внутренне не противоречивое дерево зависимостей программы, подбирая версии библиотек так, что бы не было конфликтов, даже за счёт включения более старых версий библиотек в дерево для обеспечения совместимости, иначе программа просто не запустится. Так-же и сам менеджер пакетов должен иметь внутри себя подобный solver зависимостей, для обеспечения присутствия в системе всех нужных для запуска программ библиотек, даже более старых тогда когда это требуется для формирования непротиворечивых деревьев зависимостей во время запуска программ. Ведь dll hell в рамках одной программы это явно не заложенное изначально автором программы состояние, ведь когда он создавал приложение, оно работало и не было ни какого dll hell, который приползает потом, тихо и неожиданно.
Потом уже можно и поразмыслить над возможностью одновременной загрузки разных версий библиотеки в память процесса и о том как этого достичь…
Ведь в мире совместного использования библиотек, качественные метаданные о совместимостях&зависимостях являются неотъемлемым требованием к самой библиотеке и приложению её использующему в режиме must have, и бить по рукам за отсутствие/кривизну метаданных в апстриме.
Но как раз на метаданные все хорошенько так подзабили, считая это не важным делом, а по сему имеем что имеем (
Для полного-же решения данной проблемы необходимо создать инструменты для автоматического управления версиями библиотек в репозиториях дистрибутивов и на инсталляциях дистрибутивов, а детальные метаданные о зависимостях и совместимостях библиотек должны идти с апстрима библиотеки, в виде пригодном для обработки их автоматическими инструментами.
Именно на это нужно вести политику и давить на авторов библиотек, что бы они поставляли точные, детальные и не глючные метаданные, а не создавать всякие snap&flatpack.
Как и в экономике, первый вариант приносит максимум эффективности, но подобен золотой клетке и отсутствию свободы, а второй (как и капитализм) вариант приносит минимум общей эффективности, но приносит свободу.
Ни тот ни другой вариант не приемлем для пользователя, а значит нужно искать общий компромисс с максимальным локальным результатом для пользователя. И сосуществование в системе разных версий библиотеки — это как раз такой компромисс. Причём это не отменяет возможности обновлять отдельную версию библиотеки, но эти обновления должны строжайше соблюдать совместимость ABI и вносить в общем случае только security&bug fixes.
Этот вариант — наименьшее зло. И по такому пути пошли разработчики дистрибутива gentoo, они ввели в свой пакетный менеджер понятие слотов, и каждый пакет (теоретически) может быть установлен в системе в нескольких версиях одновременно в разные «слоты». Если у нас на 1000 пакетов будет 30 версий библиотеки (что мало вероятно, скорее всего будет значительно меньше), то это гораздо лучше варианта когда на 1000 пакетов та-же 1000 версий библиотеки. По опыту работы с gentoo могу сказать, что в системе одновременно сосуществует самый максимум 3-5 версий библиотеки, а в общем по системе редко когда больше одной.
Это приведёт к плавному и безболезненному введению в эксплуатацию новых версий библиотеки, и автоматическому удалению из системы старых версий, которые не нужны больше ни одному приложению в системе. Если какое либо приложение надолго застрянет со старой версией библиотеки, то в конечном итоге во всей системе использовать её будет только это приложение, и это проблемы этого приложения, а не всей системы в целом.
Вообще эта ситуация удивительна — на дворе уже давным-давно 21-й век, а эта фундаментальная проблема до сих пор не решена, и похоже не собирается решаться.
Но проблема может быть решена под другим углом — нужно поменять парадигму понимания библиотеки, сейчас все понимают библиотеку как одну единую сущность, с которой обязаны линковаться все кто её используют. Для решения проблемы dll hell необходимо принять парадигму, что библиотека — это не одна сущность, а целый набор мало отличающихся друг от друга сущностей (разных версий библиотеки), которые должны без проблем сосуществовать друг с другом в рамках общей системы, а с какой именно версией линковаться — решает каждое отдельное приложение. Это позволит по зависимости легко и без проблем подтянуть в LTS дистрибутив новую нестабильную версию библиотеки, и использовать её будет только то приложение, которому нужна именно эта версия, все же остальные приложения в системе, продолжат использовать стабильную версию, на которую они рассчитаны.