Comments 145
А где остальная часть статьи?
Как длинно написано слово «костыли».
А еще у привычных менеджеров пакетов (вроде apt) есть фатальный недостаток
Фатальный недостаток — понятно. Если бы они решили написать более хороший пакетный менеджер — я бы им только порадовался. К тому же dpkg — фантастические претензии — очень много тьюринг-полных (баш!) мест вместо декларативности. Но подход, который они выбрали — это путь индивидуализма.
Почему меня это вообще волнует (vs «расцветай сто цветов»)? Потому что ubuntu, к сожалению, почти индустриальный стандарт для инстансов и автопровиза. Их действия могут сильно осложнить мою будущую профессиональную деятельность.
Почему меня это вообще волнует (vs «расцветай сто цветов»)? Потому что ubuntu, к сожалению, почти индустриальный стандарт для инстансов и автопровиза. Их действия могут сильно осложнить мою будущую профессиональную деятельность.
flatpak в плане зависимостей спроектирован сделан лучше snap. Емнип, у snap все зависимости в одном пакете, у flatpak от каких-то пакетов (рантайм например) может зависеть несколько пакетов, причем может быть установлено несколько версий одного и того же рантайма.
Если это превратится в 600Гб
Не защищаю flatpak. Он, как и snap, со временем на системе все равно превращается в огромную помойку, пусть и не так быстро в теории.
Кстати, это очень интересный вопрос. В принципе, весь дистрибутив должен быть на одной версии. Иногда смена версии — очень мажорная и breaking change, которые не исправить за разумные усилия. В обычных дистрибутивах это делают поддержкой нескольких версий, плюс semantic version для so'шек. И это зло, с которым мейнтейнеры должны бороться.
flatpak, наличием зависимостей, делает шаг в правильном направлении, но в сама идеология «от чего хочешь, от того и завись» ведёт к пинингу версий (т.к. меньше вероятность поломки приложения), и разрушает «общее благо» во имя локальных улучшений.
flatpak, наличием зависимостей, делает шаг в правильном направлении, но в сама идеология «от чего хочешь, от того и завись» ведёт к пинингу версий (т.к. меньше вероятность поломки приложения), и разрушает «общее благо» во имя локальных улучшений.
flatpak в плане зависимостей спроектирован сделан лучше snap. Емнип, у snap все зависимости в одном пакете, у flatpak от каких-то пакетов (рантайм например) может зависеть несколько пакетов, причем может быть установлено несколько версий одного и того же рантайма.
Неправда же. Вы, видимо, документацию snap поленились прочесть.
В обоих случаях (что snap, что flatpack) мы имеем слои. Т.е. предположим рантайм -> гном -> что-то приложение-специфическое. Любой из слоев вы можете ставить хоть 100500 различных версий, при этом приложение будет просить слой A определенной версии, который будет просить рантайм определенной версии, т.е. у каждого слоя есть «предок», который является его зависимостью.
Разница в подходах только в том, что snap умеет «плагины», т.е. возможность на одном уровне смонтировать несколько слоев при условии наличия у них одного предка, а в flatpack граф строго линейный.
У флетпака есть большая проблема — он пытается заниматься не только упаковкой приложений, но ещё и их изоляцией. Причём в принудительном порядке. В итоге запаковать во флетпак какую-нибудь IDE, которой нужно стучаться к установленным в системе тулчейнам просто напросто невозможно. Ибо кому-то пришло в голову, что это "не нужно". У snap в этом плане есть специальный режим для тех, кому таки нужно.
Вообще-то Snap подерживает зависимости. Так, после того, как KDE отделил KDE Frameworks в отдельный пакет, размер других Snap-пакетов сильно уменьшился. Подробнее: vasilisc.com/kde-app-framework-snap
Встроить библиотеки в один пакет или зависеть от других пакетов — решение разработчика.
Встроить библиотеки в один пакет или зависеть от других пакетов — решение разработчика.
Коренная проблема общего счастья здесь одна — это dll hell, из-за которого LTS дистрибутив отказывается принимать новые версии библиотек, а разработчик приложения вынужден тащить с собой свою локальную версию библиотеки.
Но проблема может быть решена под другим углом — нужно поменять парадигму понимания библиотеки, сейчас все понимают библиотеку как одну единую сущность, с которой обязаны линковаться все кто её используют. Для решения проблемы dll hell необходимо принять парадигму, что библиотека — это не одна сущность, а целый набор мало отличающихся друг от друга сущностей (разных версий библиотеки), которые должны без проблем сосуществовать друг с другом в рамках общей системы, а с какой именно версией линковаться — решает каждое отдельное приложение. Это позволит по зависимости легко и без проблем подтянуть в LTS дистрибутив новую нестабильную версию библиотеки, и использовать её будет только то приложение, которому нужна именно эта версия, все же остальные приложения в системе, продолжат использовать стабильную версию, на которую они рассчитаны.
Но проблема может быть решена под другим углом — нужно поменять парадигму понимания библиотеки, сейчас все понимают библиотеку как одну единую сущность, с которой обязаны линковаться все кто её используют. Для решения проблемы dll hell необходимо принять парадигму, что библиотека — это не одна сущность, а целый набор мало отличающихся друг от друга сущностей (разных версий библиотеки), которые должны без проблем сосуществовать друг с другом в рамках общей системы, а с какой именно версией линковаться — решает каждое отдельное приложение. Это позволит по зависимости легко и без проблем подтянуть в LTS дистрибутив новую нестабильную версию библиотеки, и использовать её будет только то приложение, которому нужна именно эта версия, все же остальные приложения в системе, продолжат использовать стабильную версию, на которую они рассчитаны.
Если у вас вместо общей на 1000 пакетов библиотеки будет 30 версий библиотеки с средним количеством в 33 пакета, то польза от существования общей библиотеки упадёт в 30 раз, а стоимость maintanance дистрибутива — вырастет. Причём, не факт, что в 30 раз. Если кто-то зависит от openssl==1.0.1f, то запаковать такую версию — не проблема. Пофиксить heartbleed — если это поддерживаемая версия — то разумные усилия. А если нет — то неразумные. Мажорные несовместимости, когда библиотеки есть в двух версиях в дистрибутиве, обычно решают (поддержкой обоих версий). А вот ситуация «с какой именно версией линковаться — решает каждое отдельное приложение» — это как раз тот момент, когда разработчику хорошо, а дистрибутиву — плохо. Про эту проблему я писал в статье.
Dll hell — проблема, возникающая от коллективного пользования библиотеками. Но это не повод отказываться от коллективных библиотек, потому что они с собой несут большее благо, чем проблем (Сравнить с общественным транспортом, например).
Dll hell — проблема, возникающая от коллективного пользования библиотеками. Но это не повод отказываться от коллективных библиотек, потому что они с собой несут большее благо, чем проблем (Сравнить с общественным транспортом, например).
Можно ввести концепцию каналов.
Допустим, nightly, stable и very_old.
Найтли — последний коммит, у которого прошли тесты.
Стейбл — последний релиз.
very_old — (подставьте сюда LTS-политику дистрибутива).
И в зависимости от этого разработчик выбирает нужный канал.
С одной стороны, это в 3 раза больше места (на самом деле нет, т.к. жирные приложения все равно в одном экземпляре), но с другой — все более-менее довольны.
А не перестанут ли авторы при этом обновлять зависимости? Поставил в зависимость версию 1 и работаешь с ней все время. А что вышла уже версия 2 и 3 — даже не в курсе. И что первая дырявая, как решето — тоже. Зачем следить за развитием библиотеки, если и старая работает?
Многим авторам и сейчас ничто не мешает так делать. Или ставьте либу мохнатой версии — или крутитесь как хотите.
Ну сейчас так делает меньшинство. В основном те, кого не колышат жалобы пользователей. Остальные же вынуждены следить не ломается ли совместимость по мере обновления пакетов.
Ну сейчас так делает меньшинство.В том-то, блин, и дело, что так делает подавляющее большинство. Просто люди, «варящиеся» в опенсорс-коммьюнити этого не понимают.
Подавляющее большинство программ в реальном мире (ну, знаете, там, где делаются журналы, варится сталь и сдаются отчёты в налоговую) — это «поделки на коленке». Которые кто-то сделал за условные 100 рублей (либо вообще по-знакомству). Да даже если и за 100000 рублей заказали у фрилансера!
Вот так же, как вы, если вам потребуется тумбочка или шкаф и вы будете делать их на заказ — так же и программы делаются. Один раз. Когда программа сдаётся — она отдаётся заказчику (хорошо если с исходниками, но частенько и без) и… всё. Совсем всё. И там некому следить за тем, «не ломается ли совместимость по мере обновления пакетов». Просто некому. Если у некоторого количества людей эти поделки ломаются при переходе, скажем, на Windows 1810 — то они изобретают способы этот апдейт не ставить. А если их набирается слишком много — Microsoft (то есть разработчик операционки, а не кто-либо ещё!) думает как их чинить.
И вот пока Linux не поддерживает подобный подход — шансов на десктопе у него не будет. Пока на десктопе были только соперники, не способные Linux убить (Windows и MacOS) — проблема не была особенно уж острой. Но если туда придёт ChromeOS или, ещё хлеще, Android — то всё. Вот совсем всё. Смысла в Ubuntu больше не будет.
Отсюда и все эти flatpak'и и snap'ы. А вовсе не из желания угодить разработчикам, которые могут реагировать на «жалобы пользователей». Не об них речь, совсем не об них.
И вот пока Linux не поддерживает подобный подход — шансов на десктопе у него не будет.Поддерживает, конечно. Вы описываете портативную программу, для этого есть, например, AppImage, или просто статическая компиляция для случаев попроще. Snap и Flatpak избыточны для необновляемых программ.
Linux apps that run anywhereappimage.org
«As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application.»
«As an application author, I want to provide packages for Linux desktop systems, without the need to get it 'into' a distribution and without having to build for gazillions of different distributions.»
AppImage не содержит никаких средств интеграции с десктопом. Ни банально добавить приложение в меню запуска, ни зарегистрировать его как обработчик его собственных файлов, etc.
Так-то можно просто статический бинарник собрать — и всё.
Так-то можно просто статический бинарник собрать — и всё.
Такая фигня используется в Windows ru.wikipedia.org/wiki/Side-by-side_assembly
UFO just landed and posted this here
типичная проблема зависимостей в python-окружении (да и вендора в golang), которая пока не имеет общего решения.
rpm-based дистрибутивы хотя бы минимум три варианта решения предлагают (не ставим 0.1.2, ставим 0.1.2 и ломаем зависимости, или тащим все подряд)…
rpm-based дистрибутивы хотя бы минимум три варианта решения предлагают (не ставим 0.1.2, ставим 0.1.2 и ломаем зависимости, или тащим все подряд)…
В целом система библиотек в линукс позволяет подобные зависимости.
Если это отличия в минорных версиях, а библиотеки соблюдают соглашения semver и замена минорной версии ничего не рушит, то SONAME у обоих библиотек будет одинаковым — например, libfoo-0.1.so (минорная версия не включена в имя), и оба пакета просто слинкуются с последней версией либы (файл libfoo-0.1.so будет симлинком на libfoo-0.1.2.so).
Если это совсем разные версии, так что линковка с libfoo-0.1.2 вместо libfoo-0.1.1 будет ломать продукт, то по соглашению они должны иметь разный SONAME, и тогда программа слинкуется с обеими версиями библиотеки.
Если это отличия в минорных версиях, а библиотеки соблюдают соглашения semver и замена минорной версии ничего не рушит, то SONAME у обоих библиотек будет одинаковым — например, libfoo-0.1.so (минорная версия не включена в имя), и оба пакета просто слинкуются с последней версией либы (файл libfoo-0.1.so будет симлинком на libfoo-0.1.2.so).
Если это совсем разные версии, так что линковка с libfoo-0.1.2 вместо libfoo-0.1.1 будет ломать продукт, то по соглашению они должны иметь разный SONAME, и тогда программа слинкуется с обеими версиями библиотеки.
Если это совсем разные версии, так что линковка с libfoo-0.1.2 вместо libfoo-0.1.1 будет ломать продукт, то по соглашению они должны иметь разный SONAME, и тогда программа слинкуется с обеими версиями библиотеки.После чего всё развалится, потому что никто не указывается версии для символов — а поиск их в ELF не учитывает имени библиотеки.
Это вопрос о детализации версий в списке зависимостей. Если детализация идёт до 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, который приползает потом, тихо и неожиданно.
Потом уже можно и поразмыслить над возможностью одновременной загрузки разных версий библиотеки в память процесса и о том как этого достичь…
Если же говорить о dll hell в рамках одного процесса в памяти, то это уже другая, гораздо более сложная проблема, с которой я тоже сталкивался. Можно подумать, что это вина автора приложения, который не проследил консистентность всего дерева зависимостей приложения, но как оказывется, дерево зависимостей приложения может поломаться уже после успешного создания приложения и внедрения его в эксплуатацию: какая то из библиотек, от которых зависит приложение обновилась и изменила свои зависимости на более свежие версии, которые не совместимы с зависимостями самого приложения или других библиотек, от которых зависит приложение.
Именно по этому я ратую за переосмысление вообще всей концепции разделяемых библиотек, от низа до верха. Во первых менеджер пакетов должен нормально и качественно обустраивать сосуществование разных версий библиотеки в системе (то как это делается сейчас путём включения номера версии в имя пакета, явно указывает на костыльность решения), во вторых сама библиотека должна осознавать, что несколько версий её же может присутствовать в системе (и даже более, могут работать в программах одновременно) и должна это учитывать, в третьих ld_linker при запуске программы должен иметь в себе достаточно умный solver зависимостей, который должен уметь выстраивать внутренне не противоречивое дерево зависимостей программы, подбирая версии библиотек так, что бы не было конфликтов, даже за счёт включения более старых версий библиотек в дерево для обеспечения совместимости, иначе программа просто не запустится. Так-же и сам менеджер пакетов должен иметь внутри себя подобный solver зависимостей, для обеспечения присутствия в системе всех нужных для запуска программ библиотек, даже более старых тогда когда это требуется для формирования непротиворечивых деревьев зависимостей во время запуска программ. Ведь dll hell в рамках одной программы это явно не заложенное изначально автором программы состояние, ведь когда он создавал приложение, оно работало и не было ни какого dll hell, который приползает потом, тихо и неожиданно.
Потом уже можно и поразмыслить над возможностью одновременной загрузки разных версий библиотеки в память процесса и о том как этого достичь…
Все правильно говорите, но мне кажется, что трудоемкость этого решения будет весьма высока. И оно будет достаточно хрупким.
А разве соблюдение непротиворечивости репозиториев дистрибутивов мейнтейнерами не есть задача очень высокой трудоёмкости? Разве это приемлемо, когда пользователю запрещается использовать более свежее ПО, а авторам программ для обхода этого запрета приходится идти по пути windows, когда любое ПО — это гигабайты и гигабайты дистрибутивов, десятки гигабайт впустую занимаются на диске, только из-за того, что каждая программа тащит с собой всё своё обособленное дерево зависимостей? Но плачут, колются, но продолжают есть кактус, просто потому что и так худо-бедно, но работает. И ни кто в общем то не стремится решать этот вопрос раз и на всегда. А поскольку проблема фундаментальна по своей природе, то и решать её нужно не спеша и основательно.
На мой взгляд здесь нет ни чего неразрешимого — достаточно один раз инвестировать усилия в реформу системы создания ПО, и потом будет очень не малый профит. А за обеспечение устойчивости, что бы ни чего не поломалось, должны отвечать беспристрастные, точные и выверенные автоматические инструменты, которые будут постоянно мониторить и тестировать репозитории, и не допускать в репозитории ПО дистрибутивов пакеты, ломающие существующие зависимости. DevOps и автоматизация рутинных задач рулит.
Но мешает данному прогрессу закостенелость устоявшейся системы разработки ПО, нежелание библиотек-старожилов реформироваться, и не желание всего сообщества пересматривать и менять подходы к своей работе, а для этих реформ нужна всеобщая кооперация, которая должна начинаться как раз с основ — с титанов держащих на своих плечах все дистрибутивы — с основных общесистемных библиотек и программ, вроде glibc и того же линкера, обеспечивающего запуск программ. А они то как раз более всего сопротивляются каким либо серьёзным изменениям.
На мой взгляд здесь нет ни чего неразрешимого — достаточно один раз инвестировать усилия в реформу системы создания ПО, и потом будет очень не малый профит. А за обеспечение устойчивости, что бы ни чего не поломалось, должны отвечать беспристрастные, точные и выверенные автоматические инструменты, которые будут постоянно мониторить и тестировать репозитории, и не допускать в репозитории ПО дистрибутивов пакеты, ломающие существующие зависимости. DevOps и автоматизация рутинных задач рулит.
Но мешает данному прогрессу закостенелость устоявшейся системы разработки ПО, нежелание библиотек-старожилов реформироваться, и не желание всего сообщества пересматривать и менять подходы к своей работе, а для этих реформ нужна всеобщая кооперация, которая должна начинаться как раз с основ — с титанов держащих на своих плечах все дистрибутивы — с основных общесистемных библиотек и программ, вроде glibc и того же линкера, обеспечивающего запуск программ. А они то как раз более всего сопротивляются каким либо серьёзным изменениям.
В литературоведении XX—XXI веков утопии, как и антиутопии, рассматриваются в ряду жанров научной фантастики.
Взято отсюда.
Взято отсюда.
Вы очень много оценки добавляете в процесс.
1. Пользователю ничего не запрещается. Произвольные репозитории и deb'ки — пожалуйста.
2. В замен на «старые версии» пользователь получает систему, которая работает, даже после апдейтов. Если в системе появляются куски, которые что-то себе на уме не так как все, то последствий от взаимодействия с соседями никто не понимает (в т.ч. пользователь).
3. Любые усилия по реформе разработки ПО натыкаются на эгалитарный анархизм. Невозможно заставить людей на erlang писать так, как пишут на питоне. Сейчас в дистрибутиве разные модели работы с разными экосистемами. У си своя модель (lib*-dev и lib-*пакеты), у python своя (модули в dist-packages), у ruby своя (version-dependent installation), у go своя (только -dev-* пакеты), у node своя, у java своя и т.д. Попытка всех их выравнять под одну гребёнку ничего хорошего не сделает, потому что за каждой из экосистем миллиарды строк кода. Можно лишь искать пути сосуществования, чем и занимается dpkg. Его принцип — каждый собирает как может, а мы потом пакуем и патчим если надо результат.
То есть тут именно сосуществование — ни мейнтейнеры не могут объяснить ВСЕМ как надо писать, ни конкретные экосистемы не могут заставить мейнтейнеров делать как им сказали (условно, пакеты собираются в отсутствие сети, так что go-way с хождением на github запрещён, так же как и pbr-way с подглядыванием в собственный git за версией — нет гита, есть только сырец).
Важно, что у каждой из этих экосистем есть причины, почему они так делают, и приходить ко всем с одинаковыми лекалами — это пытаться «всех построить». Пошлют, да и только.
1. Пользователю ничего не запрещается. Произвольные репозитории и deb'ки — пожалуйста.
2. В замен на «старые версии» пользователь получает систему, которая работает, даже после апдейтов. Если в системе появляются куски, которые что-то себе на уме не так как все, то последствий от взаимодействия с соседями никто не понимает (в т.ч. пользователь).
3. Любые усилия по реформе разработки ПО натыкаются на эгалитарный анархизм. Невозможно заставить людей на erlang писать так, как пишут на питоне. Сейчас в дистрибутиве разные модели работы с разными экосистемами. У си своя модель (lib*-dev и lib-*пакеты), у python своя (модули в dist-packages), у ruby своя (version-dependent installation), у go своя (только -dev-* пакеты), у node своя, у java своя и т.д. Попытка всех их выравнять под одну гребёнку ничего хорошего не сделает, потому что за каждой из экосистем миллиарды строк кода. Можно лишь искать пути сосуществования, чем и занимается dpkg. Его принцип — каждый собирает как может, а мы потом пакуем и патчим если надо результат.
То есть тут именно сосуществование — ни мейнтейнеры не могут объяснить ВСЕМ как надо писать, ни конкретные экосистемы не могут заставить мейнтейнеров делать как им сказали (условно, пакеты собираются в отсутствие сети, так что go-way с хождением на github запрещён, так же как и pbr-way с подглядыванием в собственный git за версией — нет гита, есть только сырец).
Важно, что у каждой из этих экосистем есть причины, почему они так делают, и приходить ко всем с одинаковыми лекалами — это пытаться «всех построить». Пошлют, да и только.
Ну, как ни крути, без оценки не обойтись. Оценка нужна, что бы понимать что к чему и почему на самом деле. Причём в моей оценке нет унижений и оскорблений, просто констатация фактов, как они есть.
1. Пользователю не запрещается, но подключение стороннего репозитория или установка сторонней deb-ки, может поломать систему, причём так, что откатить изменения совсем не просто, придётся попотеть, а обычному юзеру без продвинутых скиллов по администрированию линукса — проблема вообще не разрешима. Сам не раз боролся с системой deb-пакетов по данному поводу — удовольствие не из приятных (
2. Иногда пользователю совершенно наплевать на всю операционную систему и всех мейнтейнеров дистрибутива, обеспечивающих «рабочую систему», если он не может запустить софт, ради которого он вообще купил компьютер. Для него это уже нерабочая система. Грустно, но факт, что сложность возни с установкой софта под линуксы — одно из главных препятствий для его распространения как основной ОС у обычных пользователей. Да, не возникает проблем с установкой софта, который уже есть в официальном репозитории, но в 90%-100% случаев пользователю нужно ещё что-то, чего в репозитории нет. Да и производителям софта, подстраиваться под весь этот зоопарк совсем не хочется, и их можно понять.
3. В данном случае речь идёт только об основе операционной системы вообще, на самых низах, т.е. об экосистеме C-программ. Другие экосистемы более высокого уровня, такие как erlang, python, ruby, node, java и т.д., могут решать свои проблемы так как им интересно. Хотя проблема зависимостей она вообще то общая и у всех одинаковая. И здесь лишь вопрос о возможности прийти к консенсусу, если говорить о всеобщем принятии стандарта управления зависимостями. Но, я думаю если основа, которая состоит из C-программ, сможет сформировать подход, который докажет свою работоспособность и эффективность, то другие экосистемы наверняка начнут перенимать этот или очень похожий подход. Хотя как раз экосистема C-программ, так уж сложилось исторически — наиболее разрозненная, к сожалению.
А в общем да, вы правы, проблема в человеческой психологии, и эголитарном анархизме как её проявлении. Не доросло ещё человечество на данной планете до осознания общего блага и его ценности. Но это тема для уже совсем другого разговора.
1. Пользователю не запрещается, но подключение стороннего репозитория или установка сторонней deb-ки, может поломать систему, причём так, что откатить изменения совсем не просто, придётся попотеть, а обычному юзеру без продвинутых скиллов по администрированию линукса — проблема вообще не разрешима. Сам не раз боролся с системой deb-пакетов по данному поводу — удовольствие не из приятных (
2. Иногда пользователю совершенно наплевать на всю операционную систему и всех мейнтейнеров дистрибутива, обеспечивающих «рабочую систему», если он не может запустить софт, ради которого он вообще купил компьютер. Для него это уже нерабочая система. Грустно, но факт, что сложность возни с установкой софта под линуксы — одно из главных препятствий для его распространения как основной ОС у обычных пользователей. Да, не возникает проблем с установкой софта, который уже есть в официальном репозитории, но в 90%-100% случаев пользователю нужно ещё что-то, чего в репозитории нет. Да и производителям софта, подстраиваться под весь этот зоопарк совсем не хочется, и их можно понять.
3. В данном случае речь идёт только об основе операционной системы вообще, на самых низах, т.е. об экосистеме C-программ. Другие экосистемы более высокого уровня, такие как erlang, python, ruby, node, java и т.д., могут решать свои проблемы так как им интересно. Хотя проблема зависимостей она вообще то общая и у всех одинаковая. И здесь лишь вопрос о возможности прийти к консенсусу, если говорить о всеобщем принятии стандарта управления зависимостями. Но, я думаю если основа, которая состоит из C-программ, сможет сформировать подход, который докажет свою работоспособность и эффективность, то другие экосистемы наверняка начнут перенимать этот или очень похожий подход. Хотя как раз экосистема C-программ, так уж сложилось исторически — наиболее разрозненная, к сожалению.
А в общем да, вы правы, проблема в человеческой психологии, и эголитарном анархизме как её проявлении. Не доросло ещё человечество на данной планете до осознания общего блага и его ценности. Но это тема для уже совсем другого разговора.
2 — понятно, что конкретному пользователю тут-и-сейчас нужно-таки-поставить. Но его интересами жертвуют ради интереса остальных пользователей, у которых ровно и хорошо. В принципе, firejail умеет запускать всякую фигню в сэндбоксе, так что даже make install ничего не попортит.
3. К сожалению, perl и к счастью python, уже давно системная часть дистрибутива. Например, cinnamon использует очень много на питоне — а cinnamon — это window manager в том числе.
3. К сожалению, perl и к счастью python, уже давно системная часть дистрибутива. Например, cinnamon использует очень много на питоне — а cinnamon — это window manager в том числе.
UFO just landed and posted this here
Я вот тоже думал о таком способе решения dll hell в линухе, и как же хорошо придумали веб-разработчики со своими composer и npm, а недавно столкнулся с этим самым dll hell уже внутри приложения, которое мне пришлось поддерживать и дорабатывать.
Представьте, что вам достался legacy-код, который вы не понимаете требует стороннюю библиотеку libfoofoo-1, и от вас требуется добавить некую фичу, которая уже реализована в соседнем проекте с помощью опять же сторонней библиотеки libbarbar-2, нужно всего-то копипастнуть немного кода из проекта коллеги, и тут оказывается, что libbarbar-2 тянет за собой libfoofoo-3, которая не совместима со своей первой версией, и вот ваше приложение зависит от двух взаимоисключающих версий чужой библиотеки, а казалось, что работы там всего на полчаса...
Буквально вчера подобным страдал.
Плюнул, и со словами «фтопку бинарники», скопипастил весь зависимый код (тем более что мне надо была только одна функциональность). Поставил в комментариях — откуда этот кусок выдран (линк на коммит в гитхабе) и всё.
(но это во мне еще жива память, как был я работал на проекте со своим самописным стдлиб/стдио и правками в принтф. После которого, выдрать кусок кода из либы, раз уж простая линковка не работает, — занятие на полчасика)
Плюнул, и со словами «фтопку бинарники», скопипастил весь зависимый код (тем более что мне надо была только одна функциональность). Поставил в комментариях — откуда этот кусок выдран (линк на коммит в гитхабе) и всё.
(но это во мне еще жива память, как был я работал на проекте со своим самописным стдлиб/стдио и правками в принтф. После которого, выдрать кусок кода из либы, раз уж простая линковка не работает, — занятие на полчасика)
Заметьте, что в Windows эта проблема давным-давно решена. И даже в Linux есть решение. Вот только разработчики библиотек его не используют…
Отчасти потому, что до появления flatpak и snap упор был на полную пересборку всего и вся при любых, самых минорных изменениях и этого просто не требовалось…
Отчасти потому, что до появления flatpak и snap упор был на полную пересборку всего и вся при любых, самых минорных изменениях и этого просто не требовалось…
Заметьте, что в Windows эта проблема давным-давно решена.
Заметьте, что это не совсем правда.
Вышеописанный сценарий в Windows не работает только если разработчики libfoofoo приложили специальные усилия, чтобы не позволить двум версиям нормально жить в одном процессе.
В Linux, наоборот, по-умолчанию две библиотеки будут конфликтовать, а чтобы их «подружить» — нужны специальные усилия.
Это — довольно-таки принципиальная разница.
В Linux, наоборот, по-умолчанию две библиотеки будут конфликтовать, а чтобы их «подружить» — нужны специальные усилия.
Это — довольно-таки принципиальная разница.
Вышеописанный сценарий в Windows не работает только если разработчики libfoofoo приложили специальные усилия, чтобы не позволить двум версиям нормально жить в одном процессе.
Ну да, там же магия внутри. Магия все решает. И, конечно, это не в Windows тот же VCRedist за собой целиком таскает всё, что крупнее калькулятора…
Как раз VCRedist всё таскают именно потому, что могут. В процессе могут быть несколько libc — потому каждый тащит «проверенную».
А в GNU/Linux — это невозможно
А в GNU/Linux — это невозможно
Как раз VCRedist всё таскают именно потому, что могут.
Как раз два разных VCRedist в одном приложении ужиться не могут. Поэтому и таскают за собой нужную версию, на которой это хотя бы запускается.
А в GNU/Linux — это невозможно
В GNU/Linux невозможно принести за собой нужную версию библиотеки? Давно? Это законодательный какой-то запрет?
А что будет с прозрачностью для пользователя?
Хороший пример heartbleed. При нынешнем подходе — я обновляю openssl (либо удостоверяюсь, что на машине установлена версия пакета с устранённой уязвимостью), после чего я не беспокоюсь, что у меня есть какие-то проблемы с точки зрения безопасности, относительно этой уязвимости. При подходе описанном вами я просто буду знать, что какие-то из приложений возможно и перестали быть уязвимы.
Хороший пример heartbleed. При нынешнем подходе — я обновляю openssl (либо удостоверяюсь, что на машине установлена версия пакета с устранённой уязвимостью), после чего я не беспокоюсь, что у меня есть какие-то проблемы с точки зрения безопасности, относительно этой уязвимости. При подходе описанном вами я просто буду знать, что какие-то из приложений возможно и перестали быть уязвимы.
Такие старые и уже устоявшиеся библиотеки как openssl с очень редко меняющимся ABI, могут иметь очень слабо детализированную зависимость от версий, скажем приложения зависят только от major версии библиотеки, тогда вероятность того, что в системе окажется множество разных версий с уязвимостями, очень мала — скорее всего в системе будет только одна, регулярно обновляемая версия. А другие, более активно меняющиеся библиотеки, как например библиотеки графического интерфейса, будут иметь большую детализацию по версии. Ведь привязка зависимостей к версии на прямую зависит от частоты изменений ABI библиотеки — чем реже меняется ABI, тем меньше версий библиотеки в системе нужно.
И кстати, и сейчас, почему вы обновив библиотеку с уязвимостями, перестаёте беспокоиться? Вдруг какое то приложение внутри себя несёт более старую версию библиотеки с уязвимостью и использует её, а не общесистемную.
И кстати, и сейчас, почему вы обновив библиотеку с уязвимостями, перестаёте беспокоиться? Вдруг какое то приложение внутри себя несёт более старую версию библиотеки с уязвимостью и использует её, а не общесистемную.
Я перестаю беспокоиться. Накладки могут случаться (включая потерю всей энтропии в ssh), но это ошибки. Технический уровень maintanance в Дебиан достаточно высок, чтобы этого не случалось (как тенденции).
Такие старые и уже устоявшиеся библиотеки как openssl с очень редко меняющимся ABIКак раз OpenSSL — это библиотека со страшным ABI, которое меняется а каждой минорной версии.
Дело в том, что там куча не-opaque структур, которые меняются от версии к версии, и с которыми напрямую работает приложения. Не то, что новая версия — смена опций компилятора или настроек библиотеки ABI ломает!
В некотором смысле OpenSSL — это квинтессенция «проклятья GNU/Linux»: так как изначально шёл рассчёт на то, что все всё будут собирать из исходников, то там — черезвычайно нестабильный ABI при весьма стабильном API.
Забавно, что GLIbC — полная противоположность: невероятно стабильный ABI (Windows отдыхает), но при этом — периодически ломается API.
Ведь привязка зависимостей к версии на прямую зависит от частоты изменений ABI библиотеки — чем реже меняется ABI, тем меньше версий библиотеки в системе нужно.Вашими бы словами!.. к сожалению чуть не у половины версий библиотек версия ABI — вообще одна: 0.0.0. Означает: «да чё вы вообще пристали — некогда нам об API/ABI думать… Мы код кодим»
При нынешнем подходе — я обновляю openssl (либо удостоверяюсь, что на машине установлена версия пакета с устранённой уязвимостью), после чего я не беспокоюсь, что у меня есть какие-то проблемы с точки зрения безопасности, относительно этой уязвимости.
И абсолютно зря не беспокоитесь, стоит признать.
Для решения проблемы dll hell необходимо принять парадигму, что библиотека — это не одна сущность, а целый набор мало отличающихся друг от друга сущностей (разных версий библиотеки), которые должны без проблем сосуществовать друг с другом в рамках общей системы, а с какой именно версией линковаться — решает каждое отдельное приложение.
это очень похоже на подход, который внедрили в Windows 7+
https://ru.wikipedia.org/wiki/Side-by-side_assembly
И оно даже работает (вроде)
Как вы и написали, есть в данной ситуации два экстремума — максимально идеальное общее счастье (коммунизм, минимум свободы пользователю), и максимально жирный дистрибутив и минимум общего счастья (индивидуализм, максимум свободы пользователю).
Как и в экономике, первый вариант приносит максимум эффективности, но подобен золотой клетке и отсутствию свободы, а второй (как и капитализм) вариант приносит минимум общей эффективности, но приносит свободу.
Ни тот ни другой вариант не приемлем для пользователя, а значит нужно искать общий компромисс с максимальным локальным результатом для пользователя. И сосуществование в системе разных версий библиотеки — это как раз такой компромисс. Причём это не отменяет возможности обновлять отдельную версию библиотеки, но эти обновления должны строжайше соблюдать совместимость ABI и вносить в общем случае только security&bug fixes.
Этот вариант — наименьшее зло. И по такому пути пошли разработчики дистрибутива gentoo, они ввели в свой пакетный менеджер понятие слотов, и каждый пакет (теоретически) может быть установлен в системе в нескольких версиях одновременно в разные «слоты». Если у нас на 1000 пакетов будет 30 версий библиотеки (что мало вероятно, скорее всего будет значительно меньше), то это гораздо лучше варианта когда на 1000 пакетов та-же 1000 версий библиотеки. По опыту работы с gentoo могу сказать, что в системе одновременно сосуществует самый максимум 3-5 версий библиотеки, а в общем по системе редко когда больше одной.
Это приведёт к плавному и безболезненному введению в эксплуатацию новых версий библиотеки, и автоматическому удалению из системы старых версий, которые не нужны больше ни одному приложению в системе. Если какое либо приложение надолго застрянет со старой версией библиотеки, то в конечном итоге во всей системе использовать её будет только это приложение, и это проблемы этого приложения, а не всей системы в целом.
Вообще эта ситуация удивительна — на дворе уже давным-давно 21-й век, а эта фундаментальная проблема до сих пор не решена, и похоже не собирается решаться.
Как и в экономике, первый вариант приносит максимум эффективности, но подобен золотой клетке и отсутствию свободы, а второй (как и капитализм) вариант приносит минимум общей эффективности, но приносит свободу.
Ни тот ни другой вариант не приемлем для пользователя, а значит нужно искать общий компромисс с максимальным локальным результатом для пользователя. И сосуществование в системе разных версий библиотеки — это как раз такой компромисс. Причём это не отменяет возможности обновлять отдельную версию библиотеки, но эти обновления должны строжайше соблюдать совместимость ABI и вносить в общем случае только security&bug fixes.
Этот вариант — наименьшее зло. И по такому пути пошли разработчики дистрибутива gentoo, они ввели в свой пакетный менеджер понятие слотов, и каждый пакет (теоретически) может быть установлен в системе в нескольких версиях одновременно в разные «слоты». Если у нас на 1000 пакетов будет 30 версий библиотеки (что мало вероятно, скорее всего будет значительно меньше), то это гораздо лучше варианта когда на 1000 пакетов та-же 1000 версий библиотеки. По опыту работы с gentoo могу сказать, что в системе одновременно сосуществует самый максимум 3-5 версий библиотеки, а в общем по системе редко когда больше одной.
Это приведёт к плавному и безболезненному введению в эксплуатацию новых версий библиотеки, и автоматическому удалению из системы старых версий, которые не нужны больше ни одному приложению в системе. Если какое либо приложение надолго застрянет со старой версией библиотеки, то в конечном итоге во всей системе использовать её будет только это приложение, и это проблемы этого приложения, а не всей системы в целом.
Вообще эта ситуация удивительна — на дворе уже давным-давно 21-й век, а эта фундаментальная проблема до сих пор не решена, и похоже не собирается решаться.
Я ж и говорю, по крупным, ломающим изменениям, мейнтейнят несколько версий. Уже. В существующих дистрибутивах.
Вот примеры:
libqt4
libqt5
libzmq5 (не знаю, есть ли 4)
libtidy5 vs libtidy-0.99-0
И т.д.
Т.е. в отдельных случаях может оказаться так, что отдельные библиотеки реально надо вести несколько версий. Чаще всего это идёт в соответствии с support time апстрима, как только апстрим перестал поддерживать версию, все приложения, которые от старой версии зависили, должны либо мигрировать, либо покинуть дистрибутив (это решает проблемы немейнтейнируемой версии с будущими уязвимостями).
Мне кажется, что проблема управления зависимостями никогда не будет решена, поскольку она онтологическая. Лучшее, что мы можем получить — это инструмент, который поддерживает оба варианта (мы уже его имеем — те же so'шки), а дальше вопрос политики и уважения к окружающим.
Вот примеры:
libqt4
libqt5
libzmq5 (не знаю, есть ли 4)
libtidy5 vs libtidy-0.99-0
И т.д.
Т.е. в отдельных случаях может оказаться так, что отдельные библиотеки реально надо вести несколько версий. Чаще всего это идёт в соответствии с support time апстрима, как только апстрим перестал поддерживать версию, все приложения, которые от старой версии зависили, должны либо мигрировать, либо покинуть дистрибутив (это решает проблемы немейнтейнируемой версии с будущими уязвимостями).
Мне кажется, что проблема управления зависимостями никогда не будет решена, поскольку она онтологическая. Лучшее, что мы можем получить — это инструмент, который поддерживает оба варианта (мы уже его имеем — те же so'шки), а дальше вопрос политики и уважения к окружающим.
По моим эмпирическим наблюдениям, то как сейчас ведут в дистрибутивах сосуществование разных версий библиотеки — поверхностно и недостаточно. Оно и понятно, поскольку это делается вручную мейнтейнерами дистрибутивов, что очень трудозатратно, неэффективно, не надёжно и долго. Зачастую обновления библиотеки в рамках major версии библиотеки всё равно ломают ABI совместимость, из-за чего дистрибутивы предпочитают привязываться к более конкретной версии библиотеки и по прежнему запрещают обновление. Т.е. мы по прежнему имеем запреты на установку более свежих версий библиотеки. Сам на это не один раз натыкался.
Для полного-же решения данной проблемы необходимо создать инструменты для автоматического управления версиями библиотек в репозиториях дистрибутивов и на инсталляциях дистрибутивов, а детальные метаданные о зависимостях и совместимостях библиотек должны идти с апстрима библиотеки, в виде пригодном для обработки их автоматическими инструментами.
Именно на это нужно вести политику и давить на авторов библиотек, что бы они поставляли точные, детальные и не глючные метаданные, а не создавать всякие snap&flatpack.
Для полного-же решения данной проблемы необходимо создать инструменты для автоматического управления версиями библиотек в репозиториях дистрибутивов и на инсталляциях дистрибутивов, а детальные метаданные о зависимостях и совместимостях библиотек должны идти с апстрима библиотеки, в виде пригодном для обработки их автоматическими инструментами.
Именно на это нужно вести политику и давить на авторов библиотек, что бы они поставляли точные, детальные и не глючные метаданные, а не создавать всякие snap&flatpack.
Да, в этом вопросе я с вами согласен. Но с метаинформацией есть проблема — если начинать уважать тот же requires.txt, то там очень много пакетов припинено на рандомной версии как "==". Политика debian'а даже игнорирует этот файл, оставляя точные зависимости на усмотрения мейнтейнера.
Проблема в некачественных метаданных о библиотеке из апстрима. И именно на исправлении этой проблемы стоит фокусировать усилия — давить на автора библиотеки что бы он поставлял качественные метаданные, возвращать в апстрим исправления метаданных от мейнтейнеров дистрибутивов, вести пропаганду и политику о качественных и своевременно обновляемых метаданных и т.д.
Ведь в мире совместного использования библиотек, качественные метаданные о совместимостях&зависимостях являются неотъемлемым требованием к самой библиотеке и приложению её использующему в режиме must have, и бить по рукам за отсутствие/кривизну метаданных в апстриме.
Но как раз на метаданные все хорошенько так подзабили, считая это не важным делом, а по сему имеем что имеем (
Ведь в мире совместного использования библиотек, качественные метаданные о совместимостях&зависимостях являются неотъемлемым требованием к самой библиотеке и приложению её использующему в режиме must have, и бить по рукам за отсутствие/кривизну метаданных в апстриме.
Но как раз на метаданные все хорошенько так подзабили, считая это не важным делом, а по сему имеем что имеем (
UFO just landed and posted this here
Сорс-бейзд-дистрибутивы ни черта не решают, если разработчики библиотек об этой проблеме не думают. Чем все эти потуги кончаются — всем известно.
Если же разработчики библиотек о совместимости таки думают, а не просто код пишут «как душа просит» — то дальше есть масса решений.
Если же разработчики библиотек о совместимости таки думают, а не просто код пишут «как душа просит» — то дальше есть масса решений.
UFO just landed and posted this here
Потому что если всем на всё насрать, то рано или поздно у вас появятся два компонента, которые будут требовать внутри одной программы разных версий одной библиотеки. А так как всем на всё насрать, то символы у разных версий будут иметь одинаковые называния и никак не будут особо помечены.
Чтобы версионность работала нужно чтобы кто-то (в крайнем случае майнтейнер, но лучшем бы, чтобы оригинальный автор) об этом позаботился.
Чтобы версионность работала нужно чтобы кто-то (в крайнем случае майнтейнер, но лучшем бы, чтобы оригинальный автор) об этом позаботился.
UFO just landed and posted this here
Собственно, ваше решение с пересборкой не дает эффекта в случае линковки двух версий библиотеки внутри одной программы. Поэтому в частном случае оно работает, а в общем — некорректно.
Оно и в частном случае не работает. Если в GTK меняется layout manager (как в стабильной версии GTK3 происходило не раз) и у вас два компонента, один из которых работает с GTK+ 3.0.10 включительно, а другой — только с 3.0.16 и новее, то вы можете хоть усобираться — но вся эта конструкция «не взлетит»
Проблема давным давно уже решена, просто все настойчиво игнорируют существование решения.
Каким образом они решают проблему переиспользования кода библиотек? Никак? Тогда это то, к чему стремится ubuntu (и это грустно).
- Так как все артефакты изолированны друг от друга, в системе может быть установлено несколько версий библиотеки
- Пакеты, использующие одну и ту же версию библиотеки, используют одну и ту же библиотеку
Таким образом есть компромисс между единственно верной версией библиотеки и приложениями, таскающими всё в себе: небольшое количество версий, используемое совместно всеми.
Этот вариант уже описан в посте: имеется хороший шанс, что в какой-то момент все или почти все приложения начинают использовать разные версии библиотек и переиспользование сходит на нет.
Это зависит от того, будут ли авторы приложения указывать диапазон версий или только одну версию. В случае диапазона — широкие возможности переиспользования, причём без проблем вроде «вот в том дистре максимальная версия вот такая, а то иначе всё сломается».
Ну а в случае, когда каждому единственная версия, переиспользование не выходит. Хотя, одни версии могут быть популярней других.
В любом случае, механизм вот он, уже есть. Выбирать между крайностями не обязательно.
UFO just landed and posted this here
Есть еще подход как в NixOS, но это наверное все же больше похоже на очень продвинутую версию flatpak.
Только я вот боюсь в данном споре нет единственно верного решения, ну например часть софта у меня системная, а часть уже через flatpak, и это вполне удобно и это явно удобнее, чем держать полнейший bleeding edge и огребать баги от внезапных обновлений.
По мне, так подход nix/guix это оптимальное решение — большая часть пакетов может переиспользовать либу (это задача создателей дистрибутива), но если вдруг понадобилось ради одного пакета заиметь другую версию этой либы — пожалуйста.
Просто полный флетпэк — большой оверхед, а полный деб — слишком ограничивающе и медленно. Вместе, вроде, норм, но две системы. А никсос эти две системы сводит к одной.
Другое дело, что флетпэк и снап ещё же изолируют, но, по мне, так это зло. Не должны приложения быть изолированы, если только намеренно.
Другое дело, что флетпэк и снап ещё же изолируют, но, по мне, так это зло. Не должны приложения быть изолированы, если только намеренно.Без инсталляции и при установке рандомных приложений из стора… результат будет плачевен.
Собственно к этому все популярные системы пришли: и macOS и Windows и Android/iOS. Но там, где так было сделано изначально… попроще, конечно.
Все store'ы — это гигантский проигрыш по сравнению с apt'овой модели. В apt'овой модели вы доверяете мейнтейнерам. Они могут сделать фигню, но не намеренно. Вы имеете огромный архив доверенного ПО, которое стремится сделать вам хорошо.
Сравните это с всякого рода сторами, где приходится защищать ваш компьютер от ПО, которое вы устанавливаете — вы настолько не доверяете хламу, который там находится, что вы тратите неиллюзорные усилия на защиту от него.
Это же катастрофа. Если мне надо следить за тем, чтобы мой графический редактор не украл адресную книгу из моего почтового клиента и не отправил её каким-то левым дядям...
… охоссподи, это реально проблема на андроидах и апсторах?
… охоссподи, это реально проблема на андроидах и апсторах?
реально
Вы имеете огромный архив доверенного ПО, которое стремится сделать вам хорошо.Вот только среди этого архива нет той самом хайповой приблуды, которой хвастался Петя. И той самой игры, про которую рассказывал Вася — тоже нет.
А это значит — что весь этот «огромный архив» вас не спасёт. Linux будет безжалостно снесён и на его место будет водружена Windows. Чтобы было не хуже, чем у других.
Ну проходили же это всё во времена нетбуков! Люди — существа социальные и вы ничего с этим не сделаете…
Это же катастрофа. Если мне надо следить за тем, чтобы мой графический редактор не украл адресную книгу из моего почтового клиента и не отправил её каким-то левым дядям…Ну если соблюдать гигиену и не давать разные дурацкие разрешения разным дурацким программам — то она контролируема.
… охоссподи, это реально проблема на андроидах и апсторах?
Но, разумеется, на всех операционках, кроме тех, которыми пользуется 3-5% гиков — эта проблема… имеет место быть. Это просто неизбежность.
Окей, кто-то снесёт. Хорошая новость, что это не касается моей рабочей машины. Да и домашней тоже.
… Когда вы говорите про 3-5% гиков, вы учитываете сервера, на которых принимается как данность, что все серверные приложения не пытаются украсть у вас пароль в базу?
Как насчёт того, чтобы изолировать ssh от доступа к postgres, потому что он туда поглядывает? А ещё авторы bash'а решили, что им очень хочется иметь аналитику того, какие файлы вы смотрите. А у авторов less есть специальные причины для сбора рандомных скриншотов. А ls считает, что информация о списке файлов — это ценный актив для продажи. А cd ничего не считает, потому что он часть bash'а и уже давно всё пишет.
А уж сколько ценной информации собирает vim и emacs… Вы же в курсе, что apt (yum) — это adware и он использует уникальное положение в рыночной экосистеме для сайдлоадинга проплаченных приложений при каждом install?
Авторы grub тоже хотят кушать, так что ваши decryption keys — это вкусно.
… Когда вы говорите про 3-5% гиков, вы учитываете сервера, на которых принимается как данность, что все серверные приложения не пытаются украсть у вас пароль в базу?На серверах нонче тоже docker и Kuernetes популярны. Плюс-минус по той же принчине.
Но на сервера редко ставиться «статусное» ПО, так что там «сторы» не нужны.
Как насчёт того, чтобы изолировать ssh от доступа к postgres, потому что он туда поглядывает?ssh — это, скорее, часть инфраструктуры. А postgresl «у нормальных пацанов» от, скажем, ftp отделён, конечно. Так было ещё в прошлом веке.
Для того, чтобы всего перечисленного не происходило все системные компоненты (а всё что вы перечислили — это-таки системные компоненты) поставляются вместе с операционкой и на каждый
bash/ls/less уже логгер не нужен: всё и так уже собирается и отсылается «куда следует» самой операционкой…Окей, кто-то снесёт. Хорошая новость, что это не касается моей рабочей машины. Да и домашней тоже.Ну это временное явление. Зачем все эти потуги по внедрению виртуальных машин с поддержкой Linux в ChromeOS и Windows? Для того, чтобы решить проблему: слишком многим разработчикам, пока ещё, необходимы десктопы с Linux.
Как только эта проблема будет решена — можно будет спокойно закрутить-таки гаечки до конца и сделать так, чтобы никакая OS, кроме поставляемой с железкой, на оную железку не вставала. И всё: наступит счастье. Можно будет, как и с телефонами — поддерживать железку пару лет, потом форсированно выбрасывать. ChromeOS, правда, пять лет поддерживается… но ломать не строить — от пяти лет к двум перейти проще, чем наоборот…
Смогут ли это провернуть или нет — пока на 100% неясно… но всё туда, как бы, идёт…
Дебиан ничего никуда не отсылает без явного согласия (которое не имеет дефолтного ответа), да и в отсылке — просто список установленных пакетов для определения самых популярных в дистрибутиве. Так что софт, которому мы доверяем, и которого много — есть. Без всяких "сторов". Репозиторий тщательно сопровождаемого софта, главная цель которого — сделать пользователям лучше.
Во как бывает в этом мире.
Во как бывает в этом мире.Вы забыли два самых главных слова: пока ещё.
Да, так пока ещё бывает. Но будет ли так завтра? Я вот — ни разу не уверен.
И ещё менее я уверен что правильный подход к сохранению такой ситуации — это делать вид, что сторы вам не нужны. Вы уже имеете кучу закладок на уровне прошивки во всех современных персоналках — что заставит людей на этом остановиться?
В рамках "у вас там хорошо? ну, это временно" — спасибо за замечание. Если что, впереди гибель планеты из-за распухающего Солнца. А принципы свободного программного обеспечения были до Дебиана и останутся после.
Сторы мне не нужны, потому что ничего из того, что кладётся в снапы не является эксклюзивным. А даже если является — если это исходные тексты, их можно пакетировать. Если не является — ну, да, есть преинтереснейшая дилемма между свободным ПО и несвободным.
… Но мне очень нравится ситуация, что мой видеоредактор не копается в моей адресной книге, и мне для этого не нужно возводить заборы между ними.
Многое ПО может использовать разные библиотеки, и указание на то, какую точно версию нужно использовать остаётся на усмотрение линкера (для компилируемых языков) или обработчика файла зависимостей (pip, bundler, etc). Если все приложения в дистрибутиве собраны с одинаковыми требованиями, то наступает благодать: если в какой-то библиотеке есть ошибка, мейнтейнер этой библиотеки обновляет версию, и исправление автоматически применяется ко всем приложениям.
Вот к сожалению здесь фундаментальная ошибка, причем причина озвучена же в первом предложении цитаты. Указание на требуемую версию сделано в момент сборки приложения и "просто обновить зависимость" для исправление чего-либо недостаточно. Все, кто эту зависимость используют, должны будут пересобраться с указанием на новую версию зависимости. Не видили что ли ни разу списка обновлений в Ubuntu (в GUI)? Там по десятку раз повторяется "обновлено то-то". Очевидно, если бы приложения получали бы исправления автоматом, то такого бы не было.
Возможно, ситуацию улучшило бы то, если бы дистрибутив не принимал в свой состав приложения со слишком строгими требованиями к версиям зависимостей: приложение должно как минимум позволять допускать установку патчей для зависимостей, а не быть привязанным к конкретному патчу
Указание на требуемую версию сделано в момент сборки приложения и «просто обновить зависимость» для исправление чего-либо недостаточно
Ну если кратко — Вы не совсем правы.
Есть такие понятия, как API и ABI, и если новая версия библиотеки не ломает их — то и пересобирать приложение нет причины. Как пример — все древние приложения, собранные со старым glibc продолжают работать на новых без каких-либо модификаций.
Все, кто эту зависимость используют, должны будут пересобраться с указанием на новую версию зависимости. Не видили что ли ни разу списка обновлений в Ubuntu (в GUI)?
Исключительно проблемы
Возможно, ситуацию улучшило бы то, если бы дистрибутив не принимал в свой состав приложения со слишком строгими требованиями к версиям зависимостей: приложение должно как минимум позволять допускать установку патчей для зависимостей, а не быть привязанным к конкретному патчу
Да практически все приложения хотят просто >= X.Y && < X+1, а то, что дистрибутив сам наворотил… См. выше.
Есть такие понятия, как API и ABI, и если новая версия библиотеки не ломает их — то и пересобирать приложение нет причины.
Это в идеальном мире, например… В реальности все может оказаться более суровым. Поэтому и «предпочтительно пересобрать».
Вы забываете еще более страшную вещь — это, когда, например, втаскиваешь какой-нибудь skype-for-linux на rpm-based дистр и оказывается, что нужно доставить 10+ пакетов руками, потому что парни забыли, что их чертовы бинарники зависят от этих 10+ системных пакетов (преимущественно — всякие библиотеки).
Так что проблема действительно в культуре (а точнее — ее отсутствия) релизов сборок пакетов.
Так что проблема действительно в культуре (а точнее — ее отсутствия) релизов сборок пакетов.
Есть такие понятия, как API и ABI, и если новая версия библиотеки не ломает их — то и пересобирать приложение нет причины.Если бы разработчики библиотеки об этом думали. К сожалению подавляющее большинство разработчиков библиотек использует CADT модель — из чего и вытекает всё остальное.
Сами бинарные файлы линкуются с гораздо менее требовательным по версиям цифрам.Если бы они не только линковались, но ещё и после этого работали… но об этом — мало кто думает. Сам вопрос «я собрал мою программу с GTK 3.0, запускаю с GTK 3.28, а оно не работает» воспринимается как оскорбление зачастую.
У проблемы зависимостей нет хорошего решения. Только в разной степени плохие.
Лично я за то, чтобы подавляющее большинство софта (особенно ключевого) шло, как сейчас, через обычный пакетный менеджер. А какой-то громоздкий, коммерческий например, софт (те же графические пакеты Adobe, если они когда-нибудь доберутся до Линупса) — вполне можно поставлять в snap/flatpack/прочие контейнеры и пусть вендор сам их поддерживает.
На мой взгляд это вполне компромиссный вариант. Вендору софта не надо болеть головой за поддержку очередной Убунты, где впихнули новый мажорный OpenSSL — они его обновят внутри пакета в соответствии со своим циклом разработки.
Из минусов — закрытие уязвимостей ложится на плечи вендоров пакетов, а не дистрибутива.
Лично я за то, чтобы подавляющее большинство софта (особенно ключевого) шло, как сейчас, через обычный пакетный менеджер. А какой-то громоздкий, коммерческий например, софт (те же графические пакеты Adobe, если они когда-нибудь доберутся до Линупса) — вполне можно поставлять в snap/flatpack/прочие контейнеры и пусть вендор сам их поддерживает.
На мой взгляд это вполне компромиссный вариант. Вендору софта не надо болеть головой за поддержку очередной Убунты, где впихнули новый мажорный OpenSSL — они его обновят внутри пакета в соответствии со своим циклом разработки.
Из минусов — закрытие уязвимостей ложится на плечи вендоров пакетов, а не дистрибутива.
Тыг чем более громоздкий софт, тем больше он получает пользы от shared libraries. Условно, тот же /bin/sed прекрасно и в вендореном виде проживёт. А вот gimp — уже не очень. И LOffice — не очень. И Krita — не очень. Точнее, прожить-то они проживут, но за счёт ресурсов рабочей станции. Об этом и статья — что каждый из них будет получать преимущества от вендоринга, но если все будут вендориться, то от дистрибутива останется гигантский блоб.
Все зависит от библиотек которые софт использует. Если это приснопамятный OpenSSL (и подобные ему), то он юзается практически всеми и сидит радостно одной копией расшаренный в памяти.
А если это что-то внутренне-специфическое, либо какие-то FFMPEG/ImageMagick-подобные либы, которые использует только этот графический софт (ну может еще парочка на той же машине), то толку использования расшаренных библиотек почти никакого. При этом добавляется головняк следить за выходом всех популярных дистрибов — смотреть не сломалось ли что и чинить.
Поэтому, если мы хотим (а мы ведь хотим?) чтобы наконец-то настал «год Линукса на десктопе» :) то snap-подобный подход неизбежен.
Т.к. несмотря на мое негативное отношение к винде, возможность запустить на почти 20-летнем Windows XP достаточно большую часть современного софта, либо (что еще более важно) запустить 20-летний софт на Windows 10 — это очень большой плюс.
Линукс пока к этому даже близко не подошел, разве что LTS релизы дают 5-7 лет стабильности.
А если это что-то внутренне-специфическое, либо какие-то FFMPEG/ImageMagick-подобные либы, которые использует только этот графический софт (ну может еще парочка на той же машине), то толку использования расшаренных библиотек почти никакого. При этом добавляется головняк следить за выходом всех популярных дистрибов — смотреть не сломалось ли что и чинить.
Поэтому, если мы хотим (а мы ведь хотим?) чтобы наконец-то настал «год Линукса на десктопе» :) то snap-подобный подход неизбежен.
Т.к. несмотря на мое негативное отношение к винде, возможность запустить на почти 20-летнем Windows XP достаточно большую часть современного софта, либо (что еще более важно) запустить 20-летний софт на Windows 10 — это очень большой плюс.
Линукс пока к этому даже близко не подошел, разве что LTS релизы дают 5-7 лет стабильности.
Тыг чем более громоздкий софт, тем больше он получает пользы от shared libraries.
Скорее наоборот. Причем с двумя отрицаниями. Чем более громоздок сам софт, тем меньше вреда он получает от поставки зависимостей «в себе».
Элементарно же, софтина весом 300МБ, которая тащит за собой еще 100МБ зависимостей, которые, кроме нее самой, один фиг никому не нужны — это, конечно, плохо, но относится к разряду «разумного неизбежного зла» или «допустимого компромисса».
Сотня мелких системных утилит по 50-100Кб «полезного веса», несущих «в себе» по паре мегабайт одинаковых зависимостей — вот оно, лицо абсолютного и неоспоримого зла «как оно есть».
Условно, тот же /bin/sed прекрасно и в вендореном виде проживёт.
Сам sed — 109Кб.
Зависимости бинарника (libc, linux.vdso выкидываем, т.к. они и для snap'а базовые):
libselinux — 155Кб.
libpcre — 465Кб.
libdl — 15Кб.
ld-linux — 171Кб.
libpthread — 145Кб.
Итого, на 100-килобайтный бинарь мегабайт зависимостей (которые нужны подавляющему числу других системных утилит), что делает «полезную нагрузку» пакета равной ~10%.
В масштабах «упаковки» всех утилит, оно увеличит базовую установку (с учетом ядра и shared-частей) раз этах в 7. Вот это и называется «путь в никуда».
А вот gimp — уже не очень. И LOffice — не очень. И Krita — не очень.
А вот это уже можно оспорить. При размере пакета, допустим, в 100МБ, докинуть 20-30 метров специфических зависимостей (особенно учитывая, что вы получаете таки «полновесное приложение» без геморроя с зависимостями) может оказаться разумным выходом.
Точнее, прожить-то они проживут, но за счёт ресурсов рабочей станции.
Потеря от вендоринга зависимостей на крупных приложениях будет держаться в пределах 20-30% дисковой нагрузки, примерно. Вендоринг «мелочи» — вот это то, что «нагнет» вашу систему.
Тут ещё и софт начал сам отказываться от шаред библиотек. тот же раст и го пошли по принципу улучшения поддержки вендоринга.
Я понимаю, зачем Canonical пушит snap. Я это понимаю, и не одобряю.Вы упускаете вторую по важности фичу этих пакетных менеджеров. Snap — это, прежде всего, о разделении привилегий и изоляции программ, описания доступа непосредственно в пакете, а также о частых и быстрых обновлениях. Обычные кросс-дистрибутивные пакетные менеджеры уже были, например, 0install, а фишка Snap именно в изоляции, во внедрении модели привилегий iOS/Android на компьютеры.
Snap ещё полезен тогда, когда программа слишком бурно развивается и не имеет LTS-версии, либо если она становится бесполезна без обновлений (как пример — youtube-dl). Как правило, такие программы не поставляют в репозиториях.
Также Snap/Flatpak не привязан к какому-то конкретному дистрибутиву: если вы хотите быстро установить какую-то программу, чтобы просто её оценить, посмотреть функциональность, а в репозитории вашего дистрибутива её нет, разумно установить её из Snap/Flatpak. Или если вам нужен условный nginx с какими-то нестандартными модулями, для RTMP-вещания видео, в локальной сети на 3 человека, например. В репозиториях его нет, в сторонних репозиториях может и есть, но очень старая версия, а в Snap/Flatpak кто-то собрал и поддерживает. Что должен сделать обычный человек, не Linux-администратор, в этом случае?
Эти пакетные менеджеры не от хорошей жизни же появились. DEB-пакеты собирать даже не сложно, а унизительно: стандартных утилит для этого есть минимум 3, плюс какие-то дополнительные обертки вокруг них. Внятная документация в одном месте отсутствует, везде только какие-то куски, разъясняющие техническую часть, но не объясняющие, какой концепции следует придерживаться при создании пакетов, нужно ли выносить разные части программы в разные пакеты, как это корректно делать, как отслеживать и выпускать обновления. Чтобы разобраться в этом программисту, для которого Linux — не основная ОС, требуется несколько дней, и это только для одного формата пакетов/дистрибутива (даже у RPM между дистрибутивами различаются макросы и дефайны, не факт, что .spec из одного дистрибутива соберется в другом). Здесь Snap/Flatpak придется кстати, как для программистов, так и для пользователей менее популярных дистрибутивов.
Ну, как пользователю, пара лишних гигабайт за snap и flatpack для меня меньшее из зол, чем искать сборки недостающих пакетов или собирать руками. Я просто хочу чтобы оно работало, а не выносило мозг.
Подзаголовки тянут на ещё один сезон Игры престолов ))
… приложения, которые жирные, тяжёлые, у которых обновления нерегулярные и которые с лёгкостью могут держать уязвимости неисправленными годами… Зато некоторые из них shiny new.
Это разве проблема? Больше похоже на нытье. Касательно уязвимостей. Тезис вообще не проходит проверку временем. Условный openssl при фиксе уязвимости ломает обратную совместимость и всем клиентам этой библиотеки приходится делать новый релиз. Действительно, имеем две крайности — либо распухшие пакеты приложений «все свое ношу с собой», либо маленькие и бесполезные программки, которые так и норовят поставить очередную версию системной библиотеки. Где видится баланс? В том, чтобы отделить системную часть от прикладной. Пускай окружение будет стабильным (и производитель за него отвечает), а всякие монстры типа фотошопов и ms office тащат свои библиотеки сами.
Еще отдельный вопрос как приложения между песочницами будут обмениваться своими данными (та же автоматизация, RPC etc) — он открыт.
Если это превратится в 600Гб, то не трагедия ли это общин в чистом виде? В каждом взятом моменте мы наблюдаем локальную оптимизацию (и решение чьего-то неудобства), но вместе, сумма этих локальных оптимизаций снижает общую оптимальность системы. На мой взгляд, больше, чем локальный выигрыш каждого из участников.
Насчет локального выигрыша и глобального проигрыша (или наоборот) — в яблочко.
Я понимаю, зачем Canonical пушит snap. Я это понимаю, и не одобряю.
Я тоже понимаю и есть еще политические соображения. Я ПРОТИВ snap. Но сегодняшная ситуация с бинарными дистрибуциями rpm/deb тоже вряд ли может быть удовлетворительной (ХОТЯ битых пакетов или пакетов с битыми зависимостями стало существенно меньше, чем 10-к лет назад).
Условный openssl при фиксе уязвимости ломает обратную совместимость и всем клиентам этой библиотеки приходится делать новый релиз.Это как, поясните? Если находят уязвимость в OpenSSL, то разработчики выпускают обновления для всех веток библиотеки, мейнтейнеры обновляют ту, которая используется в дистбирутиве, и никакие программы не ломаются и не требуют пересборки. Для этого, собственно, и существуют разные версионные ветки у серьезных библиотек и программ.
Вы наивно думаете, что любую уязвимость можно запатчить путем исправления библиотеки, а не клиентского кода (т.е. кода самого приложения)? Ну-ну.
Openssl — вообще вероятно неудачный пример.
nginx, насколько я помню, таскает свою версию openssl почему-то, причем статически слинкованную. Это к примеру о хороших программах, которые инкапсулируют свои зависимости.
Openssl — вообще вероятно неудачный пример.
и никакие программы не ломаются и не требуют пересборки
nginx, насколько я помню, таскает свою версию openssl почему-то, причем статически слинкованную. Это к примеру о хороших программах, которые инкапсулируют свои зависимости.
UFO just landed and posted this here
Вы наивно думаете, что любую уязвимость можно запатчить путем исправления библиотеки, а не клиентского кода (т.е. кода самого приложения)? Ну-ну.Если эта уязвимость в библиотеке, которую использует программа, как в примере OpenSSL — да.
nginx, насколько я помню, таскает свою версию openssl почему-то, причем статически слинкованную. Это к примеру о хороших программах, которые инкапсулируют свои зависимости.Это решает администратор/мейнтейнер, на этапе компиляции. Nginx работает со стандартным OpenSSL (не требует какого-то отдельного своего форка), и в дистрибутивах он совершенно точно собирается с динамической линковкой OpenSSL.
Даже если в каких-то сторонних репозиториях его собирают со статически слинкованным OpenSSL, то это не является проблемой, покуда мейнтейнер пакета отслеживает проблемы безопасности зависимостей, и вовремя пересобирает пакет.
UFO just landed and posted this here
Wow. А я-то думал, что snap'ы — это плохо.
Прочитайте внимательно, какая ерунда по ссылке написана. Это просто не поддается критике. Написано явно ярыми противниками Flatpak.
Аргументы, что там ерунда будут?
Т.е. я не отрицаю, что материал ангажированный и очень эмоциональный и все, что там написано надо делить на два. Но нужна и оппозиционная точка зрения.
Т.е. я не отрицаю, что материал ангажированный и очень эмоциональный и все, что там написано надо делить на два. Но нужна и оппозиционная точка зрения.
The sandbox is a lieFlatpak только предоставляет возможность изоляции программ, но не требует обязательного её использования пакетами. В случае без изоляции, программа будет иметь такие же привилегии, как и любая другая программа на компьютере, запущенная от текущего пользователя.
You are NOT getting security updatesFlatpak — такой же «сторонний репозиторий», как и любой другой. Не совсем понятно, о чем конкретно идет речь в тексте, то ли об уязвимостях в базовом слое Flatpak непосредственно, то ли в пакетах программ, которые на сайтах программ помечаются официальными (наиболее вероятно). В последнем случае, это проблема не Flatpak как технологии или программы, а проблема в сборке пакета, и аргументы amarao в этой статье здесь в силе.
Local root exploit? Minor issue!Похоже на реальную проблему безопасности, которую можно использовать для локального повышения привилегий. Но стоит заметить, что сам устанавливаемый пакет автоматически это сделать не сможет, т.е. в качестве вируса использовать не получится, только для осмысленного применения злоумышленником.
С одной стороны — я понимаю автора, про жирность и уязвимости. Это проблема, да. Но с другой стороны — дистрибутивы для пользователей, а не для мейнтейнеров. А пользователю важен функционал. Его слабо интересуют потенциальные уязвимости (хотя взломов никто не любит) и размер пакетов (все, что меньше рипа фильма максимального качества — мелочь). Пользователь хочет нажать кнопку «установить» — и получить программу. Ему не хочется танцевать с бубном, выясняя, почему программа не встает. Он не хочет выяснять, какую именно версию какой библиотеки имел в виду разработчик — и не хочет знать, чем лучше та более новая версия, которая не работает. Его не интересует, какой новый функционал добавили в последней версии нужной программы, если в ней содержится регресс старой и востребованной конкретно данным пользователем функции. В конце концов, пользователь выбрал бинарный дистрибутив с менеджером пакетов, а не Linux From Scratch со сборкой софта руками прямо из cvs. А это значит, что ставить он будет пакеты. Не библиотеки, не модули, не утилиты — а пакеты.
Пользователю совсем не всё равно, сколько оперативной памяти занято. Как только начинается thrashing, становится «ой». Как только становится вместо 10-20Гб на системный диск 600+ — тоже «ой».
… На самом деле Debian — для мейнтейнеров, например. Они всё в нём решают и делают так, как им удобно. А дальше у нас будет (если каноникал не закопает snap'ы как upstart и unity) чистой воды сравнение debian VS ubuntu. И тут-то пользователи заметят разницу в системных требованиях для того же самого комплекта ПО.
… На самом деле Debian — для мейнтейнеров, например. Они всё в нём решают и делают так, как им удобно. А дальше у нас будет (если каноникал не закопает snap'ы как upstart и unity) чистой воды сравнение debian VS ubuntu. И тут-то пользователи заметят разницу в системных требованиях для того же самого комплекта ПО.
Я так скажу: если у меня, как пользователя Debian, есть возможность поставить софт через apt — я его ставлю. И если он работает — я доволен. А если нет возможности или не работает — то я этот софт предпочту в snap'е через snapd из дистрибутива, чем ставить руками. А ещё snap — это не столько зависимости, сколько инфраструктура. Не библиотеки, но среда для исполнения — в том числе, с настройками. А когда разница между двумя комплектами ПО описывается не только разными требованиями к диску, но и разной сложностью эксплуатации, появляется ценовой баланс «время-деньги» против стоимости гигабайтов. Пока что гигабайты проигрывают =)
Люблю такие критические статьи, но я «по другую сторону баррикад», чем автор. Мир Linux довольно жесток к сторонним программистам с их программами, над которыми они работают не полный день. Разбираться с зоопарком дистров и пытаться попасть в официальные репо — то ещё садо-мазо. Очень многие пользователи благодарят за мои snap пакеты программ, которые никогда не были легко представлены для пользователей. Snap пакеты можете ругать, но они из оперы «сделал раз — работает везде». Вот один из моих поводов для гордости — почти 20к пользователей
Если вы «сделали раз», то когда вы в последний раз обновляли библиотеки?
Когда собрали последний раз приложение. Может на прошлой неделе, может пять лет назад.
Но кого это волнует? Подавлющее большинство приложений для всех платформ так собирается. Да, даже для Linux: серверные или консольные приложения могут ни от чего не зависеть, кроме GLibC, а у неё всё очень неплохо с совместимостью.
Snap — это такой способ поддержать подобные приложения на десктопе…
Но кого это волнует? Подавлющее большинство приложений для всех платформ так собирается. Да, даже для Linux: серверные или консольные приложения могут ни от чего не зависеть, кроме GLibC, а у неё всё очень неплохо с совместимостью.
Snap — это такой способ поддержать подобные приложения на десктопе…
Я вам даже больше скажу… авторы программы просто болт положили на Linux и в их вики советы только для Ubuntu 12.04 и 14.04. Snap — просто спаситель такого софта. Старые ли там библиотеки — оооо даааа. А выход какой? Ещё одну программу на помойку?
Вот он суровый мир Linux на примере Дебиан
1320 «осиротевших» пакетов
3194 пакетов, которые кто-то хотел бы видеть в Debian
www.debian.org/devel/wnpp
Малейшее изменение в ОСи и если сторонний программист не следит за изменениями, то всё — пользователи попрощайтесь с программой.
Вот он суровый мир Linux на примере Дебиан
1320 «осиротевших» пакетов
3194 пакетов, которые кто-то хотел бы видеть в Debian
www.debian.org/devel/wnpp
Малейшее изменение в ОСи и если сторонний программист не следит за изменениями, то всё — пользователи попрощайтесь с программой.
сделал раз — работает везде».
Неправда, acestream ваш как раз перестал работать: https://forum.snapcraft.io/t/acestreamplayer-mpv-stopped-to-work-glibc-error/23061
Что ещё в Snap хорошо — вот выпустили JetBrains обновление IDE ломающее, точнее делающее неюзабельным поиск по файлам, я в Snap сразу откатился на предыдущую версию и запретил автоматические обновления. Не представляю, что бы я делал, если бы это обновление прилетело централизованно с обновлением Ubuntu. На самом деле представляю, конечно...
В убунту ещё не завезли снапшоты?
А в опенсусе на btrfs они уже сто лет в обед!
А в опенсусе на btrfs они уже сто лет в обед!
Вы в смысле бэкапа и предлагаете откатить всю Ubuntu на предыдущую LTS?
Так-то у меня есть и master disk железный и в виде ISO, и бэкап-диск моего рабочего места с предыдущей версией Ubuntu, так что вернуть старую версию можно примерно за минуту, но хочется-то новую версию, и только одну единственную программу оставить в старой версии.
Впрочем, проблем с апдейтами в Ubuntu практически нет (если не брать Firefox, но это отдельная истeрия), это как раз коллеги с Suse сидят годами без апдейтов, и переходят на Ubuntu только с покупкой нового компа :)
Вы в смысле бэкапа и предлагаете откатить всю Ubuntu на предыдущую LTS?
Боюсь, Вы меня не поняли. При любой установке rpm пакета SuSe делает что-то типа «точки восстановления» на основе снапшота файловой системы. Его потом легко подмонтировать и восстановить состояние системы до установки сбойного пакета (даже если GUI «не алё»). Это немного более сложная и развитая вещь, чем «просто бекап».
Ну вот прилетает апдейт с 16.04 LTS на 18.04 LTS — там устанавливаются сразу ВСЕ пакеты.
Вернуть один пакет — в общем случае это значит протянуть за собой тонну зависимостей.
Это немного более сложная и развитая вещь, чем «просто бекап».По-моему, это частный случай бэкапа, инкрементальный бэкап только для пакетного менеджера, который поможет при проблемах при установке одного пакета, но вряд ли даст вернуть предыдущую версию какого-либо одного пакета при обновлении всей системы.
Апдейт 16.04 на 18.04 должен быть атомарной операцией. Но это же убунту ;)
В этом отношении мне очень нравится подход coreos container linux, atomic, photon os etc.
Суть в том, что операционная система обновляется целиком. Потом происходит перезагрузка в новую версию. Никакого микса из пакетов и промежуточных состояний — win-win
В этом отношении мне очень нравится подход coreos container linux, atomic, photon os etc.
Суть в том, что операционная система обновляется целиком. Потом происходит перезагрузка в новую версию. Никакого микса из пакетов и промежуточных состояний — win-win
Ну я в итоге тоже отказался от инкрементальных апдейтов и перешёл на атомарные с LTS на LTS — сисадмин выдаёт настроенный винт с новой версией убунты, мне только пользовательскую папку скопировать остаётся. Никакого микса из пакетов и промежуточных состояний, и на предыдущую версию откатиться можно просто перезагрузившись и воткнув диск со старой версией — win-win.
Не-не — то, что Вы говорите — это другое.
rpm реально транзакционно ставит пакеты, в отличии от dpkg/apt ( сколько раз приходилось делать `dpkg -i --force-overwrite` или `dpkg-reconfigure` )
> сисадмин выдаёт настроенный винт с новой версией убунты
угу. Т.е. чукча — не админ, чукча — пользователь. И задействуется еще специально обученный человек. А где же магия, что все работает само, из коробки?
rpm реально транзакционно ставит пакеты, в отличии от dpkg/apt ( сколько раз приходилось делать `dpkg -i --force-overwrite` или `dpkg-reconfigure` )
> сисадмин выдаёт настроенный винт с новой версией убунты
угу. Т.е. чукча — не админ, чукча — пользователь. И задействуется еще специально обученный человек. А где же магия, что все работает само, из коробки?
Представьте себе мир, в котором все всё везут с собой…
Уже там живём. Каждый десктопный мессенджер (viber/telegram/etc) тянет за собой Qt5, который тянет за собой весь дом, который построил Джек. А самая дичь с которой довелось столкнуться: утилита для мониторинга состояния батареи UPS-а от FSP тащила за собой:
— JRE (что уже странно, но это еще цветочки)
— Tomcat (тут становится понятно, зачем был JRE, но здесь градус неадеквата резко нарастает)
— Adobe Flash Player (а вот тут уже всё...)
Короче, они что сделали: по клику на иконке в трее открывается браузер, по адресу типа localhost:6666 Томкат отдаёт какую-то статичную страничку со встроенным флешем, который, опять таки, стучится в Томкат, и рисует какие-то анимированные графики и диаграммы заряда/разряда батареи. ВСЁ.
Молодцы веб-разработчики (это сарказм) — перешли на новый уровень: мало им было тянуть на каждый чих сотни зависимостей композером/нпм, так они ещё и сервер свой принесли, и виртуальную машину для него, и ещё одну — для клиента.
Браузер, надеюсь, тоже свой запускают, не общесистемный.
Мониторилка рейда от LSI под винду (StorMan или типа того) работает практически идентично — тоже ява и локальные веб сервера. Это, похоже, заразно...
Вот не понимаю, почему установка qTox через flatpak занимает почти в 2 раза больше, чем appImage этого же qTox'а. При установке из flatpak тащит за собой KDE зачем-то.
Собственно все забыли, что побеждает всегда здравый смысл рынок. Пусть пользователь выбирает сам. Предоставьте пользователю выбор. Хочет — пусть ставить непонятный софт с сайта разработчика и сам следит за безопасностью, хочет — пусть аутсосит это мантейнерам дистрибутива, которые будут просто следить за базой CVE и списком версий, включенных в конкретный (жирный) пакет, а разработчики в свою очередь пусть предоставляют такой список (включил полностью — напиши какую именно версию в манифест), и будут просто исключать пакеты из своего репозитория, если их что-то не устравивает, чуть ли не в автоматическом режиме. Пользователь будет выбирать сам какой дистрибутив и его политика подходят ему.
Самое интересное, что такая или похожая система уже отработана на примере мобильного софта и это в большинстве случаев срабатывает.
Важно принять это как рабочую модель, а улучшения в виде разделяемых слоёв с одинаковым содержимым можно делать бесконечно.
Самое интересное, что такая или похожая система уже отработана на примере мобильного софта и это в большинстве случаев срабатывает.
Важно принять это как рабочую модель, а улучшения в виде разделяемых слоёв с одинаковым содержимым можно делать бесконечно.
<сарказм>А не нужно беспокоиться, от разрастания требований к месту, просто нужно добавить ещё один слой абстракции: файловую систему со встроенной дедупликацией. Ядро вон и в оперативке данные может дедуплицировать.</сарказм>
Люблю Ubuntu за возможность выбора: хочу делать по-нормальному и в удобном для поддержания на множестве машин виде — собираю пакеты в свой PPA, а хочу быстрое готовое решение — ставлю snap. Еще нравится acestreamplayer от vasilisc в качестве примера, где snap уместен — лютая проприетарщина с очень развесистой цепочкой зависимостей. Такому самое место иметь защиту AppArmor от snapd из коробки.
snap хорошо решает конкретную задачу — контейнер приложения с зависимостями, flatpak же устроил параллельную пакетную систему, мейнтейнеры флатпака тоже иногда ломают голову, а почему же приложение не собирается с glibc из Flatpak SDK.
snap хорошо решает конкретную задачу — контейнер приложения с зависимостями, flatpak же устроил параллельную пакетную систему, мейнтейнеры флатпака тоже иногда ломают голову, а почему же приложение не собирается с glibc из Flatpak SDK.
Sign up to leave a comment.
snap & flatpack — трагедия общин