Одним из основных нововведений Ubuntu 16.04 была поддержка snap-пакетов. В отличие от привычных deb-пакетов и rpm-пакетов, снэпы несут в себе все зависимости. Разумеется, это не первая попытка сделать подобные пакеты — до снэпов существовали AppImage, Flatpak, Orbital Apps. Поэтому вполне предсказуемо, что очередное изобретение велосипеда от Canonical не привлекло особого внимания этой весной.
Но теперь всё меняется: снэпы уже поддерживаются, помимо основанных на Ubuntu дистрибутивов, в Arch, Debian и Fedora, а также их поддержка в данный момент дорабатывается в CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt и RHEL. Более того, их поддержка добавляется в любой Linux-дистрибутив достаточно легко (в OpenWrt на это ушла неделя) и, по словам основателя Canonical Марка Шатлворта, может быть добавлена даже в Windows, хоть для этого и придётся повозиться.
Что дают снэпы:
- Простой способ распространения программ под Linux без необходимости адаптировать их под зоопарк дистрибутивов и пакетных систем и трудоёмкого поддержания работы репозиториев (либо зачастую тщетной надежды на людей, обслуживающих репозитории дистрибутивов)
- Простота использования на всём многообразии существующих и планируемых устройств для Internet of Things
- Лёгкая и при этом полноценная и безопасная интеграция в существующее окружение
- Простота установки и обновления серверных и облачных приложений
- Простота создания
- Автоматические обновления (честно говоря, я не очень понял, насколько они управляемы, и был бы рад комментариям на эту тему)
- Повышенная безопасность (снэпы минимизируют негативные последствия возможных уязвимостей)
- Простота публикации и использования стабильных, тестовых и ежедневных версий программ
- Уменьшение фрагментации и, как следствие, увеличение охвата приложений
При этом, разумеется, снэпы никоим образом не заменяют пакетные менеджеры, а служат лишь дополнением к ним. С моей точки зрения, это очень интересная и полезная инициатива, позволяющая беспроблемно использовать свежее ПО на старых стабильных версиях дистрибутивов (например, на Ubuntu 12.04, официальная поддержка которой будет прекращена в апреле следующего года). Для меня главным аргументом в пользу Ubuntu стала возможность использовать PPA, но снэпы позволят распространить это преимущество и на другие дистрибутивы Linux.
Статья основана на материалах отсюда, отсюда, отсюда и отсюда.
Комментарии (161)
mwizard
17.06.2016 09:33+1А снэпы статически слинкованы со своими зависимостями? Т.е. на гольном ядре или в пустом образе докера их запустить можно?
Fox_exe
17.06.2016 09:40+9Кароче, прощяй экономия места… То мы выкачивали гиг зависимостей только один раз, а теперь будем качать этот гиг каждый раз вместе с новой программкой, которая сама по себе может даже и мегабайта не весить…
daggert
17.06.2016 09:48+9Вот тоже самое хотел сказать.
ИМХО: Это жуткий шаг не туда. Многие сторонники линукса ставят во главу угла то что библиотеки для зависимостей не надо качать для каждой программы, а тут предлагают типичный для некоторых виндоузовских программ сценарий — возьмем все и сольем в один exe-шник.
Denai
17.06.2016 17:39+1Так одно другого вроде не исключает. Или есть причины по которым может быть Snap, но не может быть привычного варианта?
daggert
17.06.2016 20:31+2Я боюсь говнокодеров, которые станут игнорировать репозитории. Я боюсь админов-даунов, которые работают под рутом и не смогут вовремя понять что устанавливаемый ими «пак» скомпрометирован.
Metallikus
18.06.2016 03:30Да. Примерно такая же, по которой может быть ppa, но в официальные репозитории пакет никто даже не пытается протолкнуть. Вангую, что теперь будем иметь кучу софта, которому даже ppa заводить не будут.
ploop
17.06.2016 09:50+7Так вас же никто насильно не заставляет их использовать. Но в некоторых случаях это может быть очень удобно, особенно когда возникает конфликт версий зависимостей (одной софтине нужна одна версия библиотеки, другой — другая). Такое может быть при установке нового софта на старую систему или наоборот.
Разрулить можно, но это тот ещё квест.
dbanet
17.06.2016 12:30Так может надо решить проблему того, что это то ещё квест?
Я не знаю, как это делается, но если в системе так сложно запустить бинарник с теми либами, которые я хочу, а не теми, которые хочет система, то что-то в системе не так.ploop
17.06.2016 13:57+3Так эти нужные либы 1) надо найти отдельно, 2) суметь запустить с ними бинарник. Всё это можно с помощью гугла и такой-то матери, но это я и назвал квестом.
dbanet
17.06.2016 18:31За что минус?
1) Разве нельзя выкачать произвольную версию бинарника либы из системного репозитория?
2) Если кто-то распространяет бинарники без описания зависимостей, то это вроде не системы проблема.ploop
17.06.2016 18:56+2Минус не мой, не имею привычки минусовать обычную дискуссию, при том интересную.
1) Можно.
2) Зависимости есть, но прога А требует foo.lib версии 1.01, а прога Б требует foo.lib версии 1.05, то есть какую-то придётся выкачивать и класть отдельно, запуская бинарник именно с ней. А чтобы потом всё так и работало — скрипт запуска сочинять.
Может как-то и проще можно, я не эксперт в линуксах, просто пользователь.
romy4
18.06.2016 23:52А вот лучше бы была возможность программе из депенденси ставить именно те библиотеки, которые конфликтуют, себе в закрытый sandbox, вместо перезаписывания системных и использовать именно их. Обошлись бы «малой кровью».
immaculate
17.06.2016 13:39+2Кроме того, так как все они потенциально используют разные версии библиотек, будет чудовищный перерасход RAM, так как не будет работать расшаривание в памяти страниц библиотек (каждая программа из данного типа пакетов будет загружать в память свою копию glibc и всех остальных библиотек).
Если дисковое место можно особо не экономить — его в последнее время более чем достаточно, то оперативной памяти никогда много не бывает.daggert
17.06.2016 13:44+3>Если дисковое место можно особо не экономить…
А давайте всеже будем экономить?) Давайте уйдем от «хорошей практики» с 20-ти мегабайтным исполняемым файлом и игрой сапер в 120 мегабайт?
lybin
18.06.2016 05:24+2А такая тенденция и уже в проприетарном софте есть. Ide jetbrains, например, поставляется с Java внутри, да есть пакеты без, но главное чтобы в вашем дистрибутиве стояла не устаревшая джава. От Synology поддерживаю пакеты в Archlinux аналогично qt либы лежат внутри, и они не заменяемы с хост системными, толи версия толи патчи какие. Ср**ый upwork клиент тоже веду пакет, тот еще гемор делать это, софт ужаснейщий, в дистрибутиве обновился nss а ему нужен старее, а новый nss нужен другому софту, пришлось снова извращаться(с ним часто сюрпризы) Так что я за то чтобы проприетарные производители распространяли софт не только для deb а в универсальных пакетах, потому что из deb портировать на другой дистрибутив не всегда легко.
antreides
18.06.2016 16:14Не в проприетарном, кстати, тоже. Например, форумный движок Discourse — есть репозиторий на гитхабе, код открыт, но ставить предлагается только из Docker, других инструкций нет и другие пути установки не поддерживаются.
nikitastaf1996
17.06.2016 09:52Доступность snap под windows это потенциальное убийство windows.Уже веб является серьезным противником.Такие вещи как chrome api и native client.Сейчас единственное преимущество windows это большой обьем доступных приложений и enterprise.Но жизнь меняется.Может статься так так что с windows станется тоже самое что с windows phone.
MonkAlex
17.06.2016 11:01+5Вы чет совсем не в ту степь. Именно приложения выводят Windows на текущий уровень, пока их пишут, ею пользуются и снова пишут приложения.
Пока приложений в линуксах аналогичных нет и их не пишут — говорить не о чём.
chesterset
17.06.2016 18:23+5«Вендекапец — апокалиптическое событие, обозначающее смерть операционной системы Microsoft Windows или банкротство Microsoft. Чаще всего предсказывается линуксоидами и анонимными аналитиками с ЛОРа.
…
Пророчества о наступлении вендекапца появлялись после выхода ReactOS 1.0, Bolgenos 1.2, Wine 1.0, Слаки 13.0 и ядра линукса 4.0.» © Лурк
Massacre
19.06.2016 03:56Причём тут? Во-первых, у Windows уже давно есть своё решение проблемы библиотек (требуемую версию в каталог к EXE или, как вариант, в winsxs), а во-вторых да, систему определяют приложения, а не наоборот.
chupasaurus
17.06.2016 09:54-5PPA можно использовать и в Debian 8+ (поднять свой репозиторий для дебиана — это так слооожно).
Беспроблемная работа драйверов на 2.6.32, никогда не падающие Иксы и многое другое в очередном маркетинговом буллшите от Каноникал!chesterset
17.06.2016 18:25+3Да хавно этот ваш Каноникал, хавно Винда и МакОсь, Дебиан — расово верный дистрибутив. Пожалуй, ужаснее срача виндузятников и линуксоидов может быть только срач между линуксоидом и линуксоидом (у кого дистрибутив круче).
chupasaurus
17.06.2016 19:52Выбор дистрибутива — личное дело и личные проблемы.
Когда кто-то анонсирует новую убертехнологию и агитирует за её использование — ничто не мешает мне агитировать против её использования.
I.e когда 2 snap-приложения зависят от взаимоисключающих параметрах ядра — одно не заработает; когда snap-приложение не сможет в установленный X сервер — оно его уронит или не запустится.
Когда Red Hat в каждой второй публикации половину займет рассуждениями о проблемах бездомных кенгуру в Нигерии, я буду писать о том, что кто-то сошёл с ума.chesterset
17.06.2016 20:13+2Ubuntu не заменяли традиционные deb пакеты snap'ами, они дополнили традиционные deb альтернативой, которая может иметь свои преимущества и недостатки. Из плюсов:
Использование формата snap позволит разработчикам Ubuntu значительно быстрее создавать пакеты с новыми версиями рабочих окружений или прикладных программ. Особенность формата ещё и в том, что устанавливаемое с их помощью ПО изолировано от системы и не оказывает на неё никакого влияния. Подобная схема значительно более надёжна и безопасна.
Пакеты snap обладают определёнными преимуществами для программистов, создающих прикладное ПО для настольных машин, серверов, мобильных устройств или IoT. Единый инструмент избавит их от необходимости применять виртуальную среду для написания и тестирования приложений.
Разработчикам платных программ больше не потребуется отслеживать все зависимости и совместимости с различными системными библиотеками, что особенно актуально для старых версий Ubuntu. По этой причине Canonical планирует убедить программистов перевести все подобные решения из deb в snap уже осенью текущего года, тем более что их интерес тут также очевиден.
Вместе с этим, не может быть и речи про отказ от deb. Соответствующие пакеты будут поддерживаться, в том числе и в Ubuntu 16.04, чтобы быть доступными для всех желающих.
источник
Пока ярые фанатики считали килобайты установочных составляющих, Windows положила на это болт и выпускала приложения от десяток до сотен мегабайт. Когда интернет был 64 Кб/с а жесткий диск — 504 МБ это было бы проблемой, но сейчас скорость у многих под 100 Мб/с (не у всех, конечно, но скорость интернета увеличилась на порядки) и даже на бюджетниках уже можно найти под 1ТБ жесткий диск. Соответственно, один из главных недостатков нивелируется — сейчас многим наплевать, сколько весит инсталлятор. Если он даёт определенные преимущества разработчикам и пользователями — пусть будет, пусть вообще везде будет, где может быть. Ну а относительно того, что им могут заменить deb — в OpenSource всегда можно всё поправить, разработчики не обладают монополией и каждый может поменять дистрибутив на свой вкус, этим и славятся дистрибутивы Linux.
Ваш же комментарий не несёт никакой здравой критики или информации, вы просто сказали, что Debian рутой, а маркетинг Каноникал вам не по душе. Причём тут всё это?
Mako_357
18.06.2016 10:04Даже на бюджетники выгодней SSD ставить. 120 Гб SSD эквивалентно по стоимости 500 Гб HDD.
APLe
17.06.2016 11:19-3Я правильно понял, что snap-пакеты — это аналог инсталляторов Windows?
Если так, то новость замечательная, отсутствие нормальных инсталляторов — пожалуй, главное, что меня уже который год удерживает от ухода с Windows на Linux.
*собрался читать про Snap подробнее*APLe
17.06.2016 11:47+1Эээ… А за что минус? Если я не прав — поясните подробнее, пожалуйста, мне действительно интересно.
daggert
17.06.2016 11:57-7На площадке хабра не принято хвалить windows. Любые намеки на то что «запустил консоль > ввел непонятные команды для подключения ppa > ввел apt-get» неудобны конечному пользователю — караются непониманием.
PS: Я под защитой убунты!APLe
17.06.2016 12:01-1А, ясно.
Нет, я ничего не имею против консоли. Я только хочу и дальше иметь папочку, в которой лежат stand-alone инсталляторы, которыми можно пользоваться самому и давать знакомым вне зависимости от состояния репозиториев.
А будут эти инсталляторы запускаться из-под консоли, или из GUI — мне, в общем, плевать.daggert
17.06.2016 12:05Я давеча обнаружил удивительную штуку, для себя, appimage. Все в одном. Уж больно меня бесит тащить Qt в свой elementary.
APLe
17.06.2016 12:12Ага, посмотрю, спасибо.
Но я где-то год назад пытался найти способ использовать инсталляторы (и, вроде, изучил все существующие варианты) — пришёл к тому, что все существующие решения слишком кривы, чтобы использовать их для установки всего ПО в системе.
Хочется верить, что появление нативной поддержки snap-пакетов решило эту проблему.
Eklykti
17.06.2016 12:36+2Т. е. одну копию qt на всех тащить бесит, а по qt на каждое приложение — не бесит, ок.
daggert
17.06.2016 12:40Не бесит, потому как у меня всего одно приложение с зависимостями в виде Qt — Krita. Тащить ради нее 275 мегабайт фреймворка в систему я не хочу.
Eklykti
17.06.2016 12:41-1Чем оно лучше гимпа в таком случае, для которого ничего тащить и вовсе не надо?
daggert
17.06.2016 12:43+1Вы знаете, о вкусах не спорят, но у меня крита работает быстрее чем гимп и выглядит приятнее. Если еще и взять в плюсы ее развитие, которое явно быстрее чем гимп, то этот редактор банально удобнее мне.
ximaera
17.06.2016 15:49+7Перестаньте этого хотеть.
Как часто ваши stand-alone-инсталляторы обновляются? Сколько у вас в той папочке уже скопилось уязвимостей, в том числе RCE — никому неведомо. Благодаря этим уязвимостям часть инсталляторов в той папочке уже, возможно, чем-то заражена. И это не считая того, также замечательного, факта, что вы устанавливаете на свой компьютер ПО, взятое вашим приятелем не пойми откуда, возможно, с троянами и прочей нечистью, вместо того, чтобы взять проверенную версию из ненадёжного источника.
Делайте, что хотите, на Windows, но не тащите этот мусор в GNU/Linux, позязя!
P. S. И не рассказывайте, пожалуйста, про антивирусы. Антивирусы — это последнее прибежище безысходности.ximaera
17.06.2016 15:53Err, typo. «Из надёжного источника», конечно же. Поторопился, чтобы успеть исправить за 3 минуты :-(
Massacre
19.06.2016 04:11Да это прямо FUD какой-то, если не из репозитория — значит, обязательно с вирусом. Конечно, приходится проверять и обновлять вручную, зато и зависимости от внешних источников нет. И в случае глюков свежих версий можно от них отказаться до исправления…
ximaera
19.06.2016 20:16Да это прямо FUD какой-то, если из репозиториев — значит, обязательно какая-то зависимость и якобы нельзя за`hold`ить пакет.
Зависимость — только от официальных репозиториев ОС, если они накроются, то всё равно надо бежать с этой ОС подальше. И почему нельзя отказаться от какого-то определённого обновления, мне тоже непонятно.
Randl
19.06.2016 19:42+2Это один из принципов Linux — понимай что делаешь, а не твори магию, как в винде. Если творишь магию и тебе это неудобно — ССЗБ.
daggert
20.06.2016 10:16+1Вы однобоко смотрите на ситуацию.
Чем отличается установка нужной мне программы из стороннего репозитория (я на 12.04 сижу и мне не обновится просто так) и установка заранее подготовленного инсталляционного пакета с сайта производителя? Я не буду говорить о зависимостях, сделаем вид что их нет. Есть просто ppa от производителя и его-же deb выложенный на сайте. Где разница?
Отвечу вам сам-же: Ее нет. Если производителя скомпрометирует хакер Вася, то я точно так-же получу завирусованный пакет. Разницы никакой.
Про магию мне немного смешно: Что вы подразумеваете под ней? Я под windows всегда ставлю то что знаю куда и как поставится. Я качаю установщики для программ с сайтов-производителей, по возможности это портейбл-версии, и как-то ни разу не было проблем с вирусами, мейлру крапом или «магией».
И да: Я всегда понимаю что я творю в своем дистрибе и стараюсь все свести все к минимализму, в том числе наличие сторонних библиотек и демонов.Randl
20.06.2016 10:25Я отвечал на конкретную фразу:
«запустил консоль > ввел непонятные команды для подключения ppa > ввел apt-get» неудобны конечному пользователю — караются непониманием.
вне контекста snap-пакетов (которые, ИМХО, бесполезны, но вполне в стиле оказуаливания Linux'а от убунты и наверняка кому-то понравятся).
Про магию мне немного смешно: Что вы подразумеваете под ней?
Когда ты вводишь "непонятные команды", меняешь значения регистра, которое ты понятия не имеешь на что влияет и т.д. 95% инструкций для решения проблем на Win вообще не подразумевают осознания собственных действий. Многие сисадмины решают проблемы "рецептом" из набора. Конечно некоторые делают такие инструкции и для Linux, но это как раз перенос Win-way на Lixux.daggert
20.06.2016 10:53+1Процентов 100 того что я печатаю каждый день в eclipse, будет непонятно случайному обывателю. Сто процентов вещей я не пойму придя в соседний кабинет, где работают люди из не IT сферы, и уж точно на 147% я не пойму придя в бухгалтерию. Понимаете аналогию?
У меня есть рабочий линукс, так получилось что он у меня есть. Развиваться в сисадмина я не хочу, потому что а) это мне не нужно б) я не заинтересован вовсе в изучении данной темы за свое личное время в) мне за это не платят. По этому я на каждый чих активно гуглю. Некоторые проблемы решаются быстро, как например установка обычных прав на usb устройства, и я понимаю что я пишу в терминале, но иногда я месяц бьюсь головой об стену над кем-то написанным скриптом и не могу понять что там написано, как например было с компиляцией VLC под старым ядром. Я тупо взял этот скрипт и запустил, все.
Изучать его и понимать меня не заставите под дулом пистолета. Я никогда не поверю что все повально пользователи линукса изучают досконально все что они копируют с инета. Solved solution нашли > скопировали > чуток подправили > запустили. Не все линуксоиды испытывают радость от решения проблем, потому как проблема зачастую мешает им выполнить их работу, а не просто «интересная фигня».
PS: И это не перенос win-way в linux, это перенос удобства. Пользователю удобно когда запустил — работает. Если вы считаете иначе — вы лжете сами себе.Randl
20.06.2016 11:02Процентов 100 того что я печатаю каждый день в eclipse, будет непонятно случайному обывателю. Сто процентов вещей я не пойму придя в соседний кабинет, где работают люди из не IT сферы, и уж точно на 147% я не пойму придя в бухгалтерию. Понимаете аналогию?
Именно поэтому обыватель не работает вместо вас, а вы не работаете в бухгалтерии. Понимаете аналогию?
Не все линуксоиды испытывают радость от решения проблем, потому как проблема зачастую мешает им выполнить их работу, а не просто «интересная фигня».
Для мня решение проблемы подразумевает уверенность в том, что проблема больше не появится и устранена её причина, если это возможно. Шаманство по инструкции из интернета такой уверенности не дает, и потому меня не устраивает.
Solved solution нашли > скопировали > чуток подправили > запустили.
По опыту, за пределами ubuntu-подобных таких решений без объяснения что они делают в разы меньше. по крайней мере несколько лет назад было так.
И это не перенос win-way в linux, это перенос удобства.
Нагугленное непонятное решение зачастую тянут за собой проблемы, которые неочевидны, если не понимаешь, что делаешь. Для которых гуглишь очередное решение, которое тянет…
Я никогда не поверю что все повально пользователи линукса изучают досконально все что они копируют с инета.
Я знаю немало людей, которые пользуются компьютером при помощи записанных на бумажке пошаговых инструкций, состоящих из пунктов типа "для сохранения нажми кнопку "сохранить"".ploop
20.06.2016 11:09Я знаю немало людей, которые пользуются компьютером при помощи записанных на бумажке пошаговых инструкций, состоящих из пунктов типа «для сохранения нажми кнопку „сохранить“».
Однако, они им пользуются. Хорошо или плохо, но пользуются.
Линукс уже перестал быть системой «для гиков», и люди в нём просто работают. Вот у меня, например, с 2009 года нет win даже в дуалбуте, и дома, и на работе, и я впадаю в ступор, когда знакомые просят что-то помочь, так как уже забыл эту систему. А в линуксе чувствую себя гораздо комфортнее, хотя не являюсь специалистом, просто пользователь. И в случае проблем — гугл, а глубина понимания моих действий зависит от того, есть ли время или желание разобраться, если нет — то слепо «по рецепту».Randl
20.06.2016 11:27и я впадаю в ступор, когда знакомые просят что-то помочь
И в случае проблем — гугл
Дык, какая разница для какой системы гуглить.ploop
20.06.2016 11:37Это понятно, но с линуксами гуглить приходится гораздо реже, т.к. систему знаешь лучше, и банальные вещи делаются на автомате. Но с виндой есть плюс — всегда помогает «звонок другу», так как там все «специалисты» :)
daggert
20.06.2016 11:44>>Именно поэтому обыватель не работает вместо вас, а вы не работаете в бухгалтерии. Понимаете аналогию?
Аналогия не удачна. Моя работа — не изучать дебри линукса и разрабатывать его, моя работа делать сугубо два программных продукта под windows, вот уже 10 лет.
>>Для мня решение проблемы подразумевает уверенность в том, что проблема больше не появится и устранена её причина, если это возможно. Шаманство по инструкции из интернета такой уверенности не дает, и потому меня не устраивает.
Я был тоже так уверен, до того момента как я начал работать с x265, теперь проблемы регулярны. Про проблемы с жестким диском и sata приводом я умалкиваю.
>>По опыту, за пределами ubuntu-подобных таких решений без объяснения что они делают в разы меньше. по крайней мере несколько лет назад было так.
FreeBSD, puppy linux, QNX, FreeRTOS — выбирайте. В любом из этих вещей я пользовался «тупыми» ответами из гугла, где было ~50 строк листинга и описание на одно-два предложения.
>>Нагугленное непонятное решение зачастую тянут за собой проблемы, которые неочевидны, если не понимаешь, что делаешь. Для которых гуглишь очередное решение, которое тянет…
Кривое решение которое ты понял (как ты думаешь) но которое не правильное приводит к восстановлению бекапа который был сделан кривым решением которое ты понял (как ты думал)… и это история из практики, когда собственный бекапер посчитал что надо грохнуть весь бекап на удаленном сервере резервного хранения. До этого я думал что я знаю хоть немного баш.
>>Я знаю немало людей, которые пользуются компьютером при помощи записанных на бумажке пошаговых инструкций, состоящих из пунктов типа «для сохранения нажми кнопку „сохранить“».
И это великолепно! Я работаю в месте где из 55 человек 50 не сможет ответить какая у него ОС и что такое раскладка, однако они успешно продвигают науку, при помощи компьютера используемого как записная книжка и поисковой машины! Это и есть средний пользователь: для него компьютер лишь средство для достижения своей цели, а не сама цель. Он может быть гениальным ботаником, но ходить в шапочке из фольги потому что у него дома wifi.
xRay
17.06.2016 11:54+9Лучше бы в Windows появился нормальный менеджер пакетов по типу apt или yum, а не этот ад с существующим зоопарком инсталяторов.
Gorthauer87
17.06.2016 12:02+1Люди вот вполне полноценно pacman портировали и запилили поверх него msys2, как-то не помогает. Проблема с пакетным менеджером в винде это капля в море.
Alexey2005
17.06.2016 12:38+2Лучше бы в Linux избавились от зоопарка пакетных менеджеров. А то помимо системного пакетного менеджера каждая среда программирования норовит поставить свой собственный, ни с чем не совместимый. Все эти pip'ы, npm'ы и прочее, которые лишь создают дополнительные проблемы и конфликтуют друг с другом. И периодически приходится заниматься примерно таким шаманством:
А просто когда-то давно пакеты старых версий были установлены через dpkg, и теперь pip не может их обновить. После удаления через системный пакетный менеджер всё сразу поставится как надо…
Всё это шаманство было бы не нужно, если бы сразу все зависимости поставлялись вместе с приложением единым бандлом. Поэтому snap-пакеты могут сильно упростить жизнь, когда начинается какая-нибудь ерунда с зависимостями.TargetSan
17.06.2016 23:28+1Не избавятся. Потому как эти ПМы работают для питона/руста/голанга/чего-нибудь ещё. Не для линукса. И их задача — давать единый доступ к пакетам и на Windows, и на Ubuntu, и на MacOS, и на воон той кофеварке. Для решения таких косяков надо просто не пускать (условно) питоновские пакеты в DEB/PPA/whatever. Им там не место.
lybin
18.06.2016 05:38Это выглядит что пакет retext плохо сконфигурирован в вашем дистрибутиве, либо вы поигрались с питоновским окружением, потому что есть пакетный менеджер и паралельно глобально использовать и менять версии через pip плохо. Если нужно другое окружение питона — создайте отдельное окружение с необходимыми пакетами и версиями. Если нужно собрать пакет — указываете в зависимостях версии библиотек. И то что у вас нас скриншоте не должно происходить.
Xaliuss
17.06.2016 17:38+1В принципе сейчас майки продвигают магазин и платформу UWP во многом из-за всевозможных инсталяторов. Там и программа попадает только в папку по сути и ничего за собой не тянет, и обновление с удалением тоже организовано средстами системы. Да и безопасность выше, если мне понадобится какая-то маленькая программа или утилита, я сначала буду смотреть в магазине.
Текущие инсталяторы в винде зло, так как они часто не следуют гайдланам, и к ним стараются кучу всего прицепить (все библиотеки и фреймворки, как мы в этом топе и обсуждаем). Из-за совместимостей и придумано альтернативное API UWP. Есть конечно с этим и проблемы, но я не думаю что в обозримом будущем винда откажется от win32 приложений.
Massacre
19.06.2016 04:16+1Для гурманов есть Windows Store :) Но центральный репозиторий является одновременно и центральной точкой отказа, так что посижу я, пожалуй, со своим зоопарком локальных инсталляторов…
TargetSan
17.06.2016 12:42+6Побуду Кэпом. В линуксе давным давно есть пакетные менеджеры с UI.
А теперь внимание. В Windows вы тащите инсталлятор. Руками. Ставите его. Инсталлятор ставит свой обновлятор и ещё кучу мусора. Плюс ещё по копии уже установленных системных либ. Когда вам не нужно это приложение — вы сначала сносите его, а потом долго и скрупулёзно вычищаете зависимости. Руками. Это если один из инсталляторов не был криво написан — так, что валится на процедуре деинсталляции.
Теперь линукс. Вы заходите в пакетный менеджер — и ставите нужный пакет. Вам не нужно думать, что для этого пакета надо доустановить ещё Mono и Python. Когда выходят апдейты — их наличие проверяет один (!) сервис. Который вы настроили один раз. Когда вам не нужен пакет — вы через тот же интерфейс пакетного менеджера помечаете его на удаление. После чего пакетный менеджер сам (!) проверяет, какие пакеты больше никому не нужны, и предлагает их удалить за компанию.
Пишу вам как человек, который почти всю свою сознательную жизнь просидел на Windows, а на Linux перешёл прошлой осенью.APLe
17.06.2016 13:00+1Это удобно, кто же спорит?
Но:
1). Для установки зависимостей нужен интернет, который не всегда есть под рукой.
2). Для установки зависимостей нужно, чтобы эти зависимости (и сами устанавливаемые программы) всё ещё были в репозиториях, а не оказались удалены за ненадобностью. Не доверяю облакам — может быть, и зря, но я по жизни параноик.
3). Тут уже писали, что из-за использования зависимостей возникают проблемы использования нового ПО под старой системой. Для меня, любителя пользоваться десятилетней ОС и зоопарком программ разного возраста, это неприятно.
4). Что касается автообновления, то я его вообще всегда стараюсь отключать. Обновляться мне удобнее тогда, когда есть время разбираться с новшествами, читать мануалы и всё такое.
Понятно, что проблемы связаны с моим личным характером в целом и стилем использования компьютера в частности, но за всех я и не говорю.TargetSan
17.06.2016 17:28+11) Никто вам не мешает на другой машине выкачать пакет вместе с зависимостями. И поставить на целевой машине в оффлайне. К слову, под Windows онлайн-инсталляторы нынче в моде.
2) Аналогичная проблема с инсталляторами. Вендор удалил инсталлятор с сайта — и его больше негде достать.
3) Это так, чистая правда. Не хватает нового поколения пакетных менеджеров — смеси WinSxS хранилища и управления зависимостями APT, c «мягкими» версиями.
4) Опять же, для случая с APT вы его отключите в одном месте ровно один раз. А когда у вас Java Update + Chrome Updater Service + whatever…
В общем, пока две основные болячки пакетных менеджеров — бандлы, которые придут в виде снап-пакетов, и множество версий библиотеки на одной платформе. Но это как-то лучше, чем вообще без пакетного менеджера.APLe
17.06.2016 21:591). Да, я знаю. Я, когда понял, что в Linux проблема с инсталляторами, несколько дней разбирался, как её обойти. Можно, но очень криво получается.
1a). В моде и под Windows, да. Но под Windows при желании всегда можно найти оффлайн-инсталлятор. Я, по крайней мере, не разу ни сталкивался с его отсутствием.
2). Его можно взять со своего жёсткого диска, в первую очередь. Ну и вероятность того, что где-то на сайте-зеркале сохранился один инсталлятор, выше, чем вероятность сохранения всех зависимостей.
Я знаю, что можно вместо папки инсталляторов сохранять папку со скачанными зависимостями, и планировал это делать при уходе на Linux — но это, всё же, не очень удобно.
4). Централизация — это да, этого не хватает.
tsukasa_mixer
17.06.2016 18:25ничто не мешает делать локальные репозитории на те-же дисках или в виде некоторого контейнера и устанавливать из него. и интернет не нужен и установочник под рукой.
APLe
17.06.2016 22:05Да, примерно этим я и собирался заниматься. Но инсталляторы удобнее.
tsukasa_mixer
20.06.2016 15:43вот кстати, а что мешает сделать формат инсталяторов для локальных реп, в openSUSE подобное есть «1 click install».
Это мне кажется вполне не плохой идеей. Ложить туда все что нужно, но по сути что-бы все было через пакетный менеджер.
psyriccio
19.06.2016 15:38оффлайн инсталяция для archlinux, например
1) скрипт который получает список пакетов зависимостей нужного пакета
pacman -Si $@ 2>/dev/null | awk -F ": " -v filter="^Depends" \ '$0 ~ filter {gsub(/[>=<][^ ]*/,"",$2); gsub(/ +/,"\n",$2); print $2}' | sort -u
2) скачиваем, но не устанавливаем пакет с зависимостями в директорию /tmp/soft_pack
pacman -Sw package_name --cachedir /tmp/soft_pack
3) ну там делаем tar.gz из того что получилось или что-нибудь другое по вкусу
Когда надо установить — распаковываем и ставим ( pacman -U .)
Можно написать скриптик которому даешь название пакета, а он выкачивает все зависимости (или берет из кэша, или даже строит из установленных в системе файлов ) и упаковывает uber-tar.gz
можно даже распаковать все пакеты и объединить в один большой arch-пакет
Но так делать плохо, без лишней на то необходимостиisden
19.06.2016 16:46http://manpages.ubuntu.com/manpages/precise/man8/apt-zip.8.html
https://wiki.debian.org/AptZippsyriccio
19.06.2016 17:54Ну да, а еще можно запаковать кэш pacman в squashfs, потом когда надо монтировать и подключать как репозитарий.
А еще есть не завязанный на ubuntu AppContainer
https://coreos.com/rkt/docs/0.5.6/app-container.html
Для ArchLinux есть archci, собирает любой пакет/пакеты в AppContainer
https://github.com/paulavery-rkt/archci
Тут большой ещё вопрос — snaps завязан только на ubuntu-base, как основу любого пакета?
Т.е. грубо говоря взяли docker и сделали так, что все контейнеры будут только на базе ubuntu-base?
Если это так, то это поведение очень напоминает одну компанию, не скажу какую.
Radjah
17.06.2016 13:12-1WinSxS, MSI? Не в курсе?
daggert
17.06.2016 13:14+1«WinSxS — эта та папка что весит 47 гигабайт на диске С? Я ее удалил» //sarcasm
TargetSan
17.06.2016 17:14+2WinSxS это не депенденси менеджмент ни разу. Это просто свалка одних и тех же библиотек разных версий. Причём даже без мягкого версионирования. В рамках WinSxS нельзя зависить от «любой 2.1 выше 2.1.9». А ещё их гениальнейший способ очистки — просто вычищать пакеты, к которым не обращались месяц или около того. Гениально, что сказать.
Radjah
17.06.2016 19:44+1А в линуксе-то рай! Захотел в Debian 8 пакет из Debian 9 или даже sid. А вот перехочешь, потому что эта либа старая совсем, вот той в 8 вообще нет, а чтобы обновить эту надо чуть ли не ядро менять.и половину системы обновлять. Ну или делаем из Дебиана Слаку с помощью «make install»/«checkinstall». Или городим огород в docker/chroot/nspawn
Захотел самую свежую версию приложения в винде? Скачал, поставил, пользуешься. Загрузчик сам подбросит нужные либы.
Примеры? C помощью dpkg-buildpackage собрать wget и все его зависимости по части tls.
И как аккуратно обошли MSI, типа я и не говорил про него.TargetSan
17.06.2016 23:23Начну с конца. Про MSI не писал специально, т.к. опыта не сильно много. Но по тому, что есть — это формат-динозавр, на редкость монструозный и кошмарненький. Но это не экспертное, а сугубо личное мнение. Да и как он помогает в этом случае — не совсем понятно.
По поводу всего остального — да, невозможность держать несколько версий одной зависимости это проблема. Большая проблема. Её пытался решить NixPM. Однако, при работе с репозиториями бОльшая часть пакетов согласована. Косяки есть везде. И, как по мне, с пакетным менеджером лучше, чем без него.Radjah
18.06.2016 00:10> Про MSI не писал специально, т.к. опыта не сильно много.
Но качать кривые инсталляторы и ругать систему всегда лучше.
> Да и как он помогает в этом случае — не совсем понятно.
google://транзакции
wolf_schulz
17.06.2016 15:02Видимо человек не знает об Uninstall Tool
TargetSan
17.06.2016 17:11Если Вы про меня, я как раз знаю. Я только не понимаю, почему для того, чтобы корректно удалить программу в Windows, надо скачать другую стороннюю программу. Похоже, кто-то знает Windows лучше, чем инженеры MS.
daggert
17.06.2016 20:36Установка/удаление программ стандартная мб?
TargetSan
17.06.2016 23:25+1Вы когда-нибудь ставили Visual Studio 2012 или 2013? Эта зараза пихает в систему ещё 30-40 компонентов. Ну и классика жанра, когда программа гадит в реестре, а при удалении за собой не подчищает.
Eklykti
17.06.2016 23:37+1эта шткуа просто запускает бинарь, который инсталлер указал в реестре в качестве способа удаления того что он туда наустанавливал. Сама система ничего не отслеживает и ничего не удаляет, в отличие от пакетных менеджеров в линуксах. Качество работы анинсталлера остаётся на совести его авторов.
daggert
18.06.2016 00:28+1Ну вот из недавнего похожего в линуксе — поставил пакет, который с собой притянул еще три десятка зависимостей, включая midi эмулятор и демон работающий с ALSA. По удалении оказалось что удалились не все пакеты, так как система посчитала что демон теперь будет на постоянной основе жить в системе.
Тут вы правы, все на совести автора, по этому я и юзаю sandboxie (:
creker
18.06.2016 22:56И каким образом пакетный менеджер что-то отслеживает? Он удалять умеет только то, что сам скопировал, т.е. ничего он не умеет. А весь тот хлам, который поставили установочные скрипты и само приложение, он никак не трогает, потому что про них не знает и знать не может. Все на откуп добросовесным разработчиками, т.е. ровно тоже самое, что и с инсталляторами. Для решения этой проблемы и придумали всяческие песочницы. В винде это сейчас в виде Windows Store, где помимо UWP и для обычных win32 приложений поддержка уже есть. Постепенно, но порядок наводить начинают.
Хуже всего конечно в макоси с pkg установщиками, которые ставят непонятно что непонятно куда и удалять это никто не умеет. Можно только надеяться, что приложение где-то содержит кнопку «uninstall».isden
19.06.2016 10:42> Хуже всего конечно в макоси с pkg установщиками
В большинстве случаев оттуда довольно не сложно извлечь сам *.app и руками положить его куда нужно. Иногда там бывают какие-то post/pre install скрипты, которые можно посмотреть глазами и запустить если нужно. В редких случаях попадаются ядерные модули или модули настроек.
Хотя, конечно, из App store ставить проще.mwizard
19.06.2016 12:43Просто кто-то таки должен взять ситуацию в руки и сделать конвертер из pkg в формулы homebrew в один клик.
isden
19.06.2016 12:49Что-то мне сомнительно, что в homebrew примут коммерческий / закрытый софт без исходников (плюс еще могут быть заморочки с EULA, там где запрещена декомпиляция / расковыривание софта)…
Хотя можно, конечно, свой локальный реп держать.mwizard
19.06.2016 12:53Не, суть как раз не в том, чтобы ставить их из репозитория — я думаю скорее о деинсталляции
пиратскогосамодельного софта. А так — дропнул pkg на "конвертилку", а оно конвертит в формулу и ставит в /usr/local/, вне зависимости от лицензии и происхождения этого pkg. А потом удаляет оттуда же.isden
19.06.2016 12:59> и ставит в /usr/local/
Тут может быть облом. Мне попадался софт, который хочет быть строго в /Applications, изо всех остальных мест (даже из ~/Applications) он просто не запускается. Симлинки тоже могут не прокатить. Из недавнего — BusyCal. Немного порылся в бинарниках/ресурсах — там этот путь хардкодом в куче мест.
creker
19.06.2016 17:53Во-первых, не всегда это просто *.app. Для таких простых случаев есть обычные dmg образы. Любят еще ставить апдейтеры всякие, плагины для настроек, демоны и прочие вполне обычные штуки. Во-вторых, приложения в макоси любят складывать хлам по всей файловой системе, что потом это вычищать только с помощью специальных утилит приходится. Даже эпл программы этим страдают. Тот же Xcode вроде бы ставится из AppStore, но свой мусор ткает везде и всюду. Тут и AppStore уже не помогает. Им стоит все таки больше брать пример с iOS, где порядка в файловой системе и с приложениями намного больше. Или с Windows Store, который может навести порядок даже для обычного win32 софта путем виртуализации файловой системы и регистра, чтобы потом одним кликом удалить все и вся без всяких скриптов и вмешательства разработчика.
Gorthauer87
17.06.2016 15:05+1Проблема тут только в том, что рук уже не хватает, чтобы следить за огромной базой пакетов и программ, которые к тому же еще и растут как грибы после дождя. При этом авторы программ и библиотек не могут себе позволить просто универсальный пакет сделать, который можно было бы просто скачать и использовать. То есть штуки типа snap реально нужны, но в реальности нужна лишь одна такая вещь, которая бы была доступна в любом дистрибутиве. Но они не замена системным пакетным менеджерам.
SchmeL
17.06.2016 15:44скажу на примере проекта openmcu-ru. Проект использует специальные патченные версии библиотек ptlib и h323plus, которые конфликтуют с оригинальными системными, поэтому эти библиотеки идут вместе с основным проектом. (не всегда можно договориться о включении новых фич в основной репозиторий библиотек) Так же проект зависит от ffmpeg определенной версии, который в некоторых дистрибутивах avlib.
Поэтому в данный момент чтобы все работало основное приложение нужно ставить специальным скриптом.TargetSan
17.06.2016 17:17+1Увы, пакетные менеджеры не совершенны. Была как минимум одна попытка скрестить хранилище в стиле WinSxS и зависимости в стиле DPKG/APT — Nix Package Manager. Не взлетела. А было бы очень приятно иметь такую штуку.
Gorthauer87
17.06.2016 12:08+1Судя по доке, создавалка snap пакета по формату очень похожа на конфигурационные файлы travis'а или appveyor'а. Подозреваю, если идея взлетит, то всяким юзерским программам станет проще деплоится. Только вот в flatpack есть такая штука, как платформы, которые шарятся между приложениями, тут я пока вижу просто build-parts, в которую нужно вписать инструкции сборки всех зависимостей, что не очень то удобно.
Bytamine
17.06.2016 12:29+3снэпы минимизируют негативные последствия возможных уязвимостей
Каким образом?
Если раньше надо было обновить одну уязвимую библиотеку, то со снэпами надо будет обновлять каждый снэп, который от неё зависит. Так?alexkunin
17.06.2016 12:46Одну библиотеку, а также все статически слинокованные приложения и библиотеки. Еще, если вы собрали что-то из исходников (например, потому, что линукс на сервере древний, и в его репках нет какого-нибудь пхп7), то вам придется пересобирать (с момента «скачать зависимости»). Но это мои домыслы, а также непосредственный ответ на ваш вопрос про уязвимости в библиотеках.
А вот что в оригинальных статьях:
Each snap is confined using a range of kernel isolation and security mechanisms, tailored to the snap, ensuring that vulnerabilities in the application are contained to the greatest degree currently possible. A careful review process ensures that snaps only receive the permissions they require to operate. Users do not have to make complex security decisions when installing the snap.
Т.е. снэп — не просто тар-файл со всеми зависимостями: приложение изолируют, ограничивают их допуски (как на андроиде, я так понимаю: можно микрофон и контакты, остальное нельзя). О проблемах обновления в случае уязвимостей (в приложении или зависимостях) речи нет.4144
18.06.2016 03:35+1xserver обнуляет все эти защиты. snap приложение может просто включить кейлогер и собирать рутовые и другие пароли.
alexkunin
18.06.2016 09:00+1Говорят, «sandbox -X ...» помогает: запускается nested xserver для изоляции и что-то там еще. Но да, иксы — одна большая дырка, пофиксить которую нереально. Может Waylend поможет? Или Mir? Или я запутался, что там будет следующее.
vanxant
17.06.2016 12:39Это чего, теперь у каждого скрипта на питоне в инсталляхе будет полдистрибутива, начиная с libc?
severgun
17.06.2016 15:05будто раньше не так было. pip'ом весь мир к себе скачай чтоб скрипт 2+2 посчитал.
vanxant
17.06.2016 19:32Эх, мне казалось, что dll hell остался только у некоторых не особо удачливых скриптовиков в их замкнутых мирках с кривыми менеджерами зависимостей и 15 несовместимыми стандартами языка и библиотек.
А тут похоже они собираются расширить свой адок на всю систему.
andrzzc
17.06.2016 12:41Разве .deb-пакеты не предоставляют такую возможность на данный момент?
Например можно поставить пакет busybox или busybox-static.
У busybox-static преимущество в том что консоль не сломается если внезапно отвалится корневой каталог / на котором хранятся все либы.
В целом мне кажется это «пятнадцать конкурирующих стандартов».
Теперь разработчикам snap-пакетов придется постоянно следить не обнаружился ли в их пакете очередной SSL Heartbleed.
MasMaX
17.06.2016 15:12Deb тащит просто упоминание о зависимых пакетах. Но ни ссылок, ни самих пакетов он не несет
andrzzc
17.06.2016 15:19Deb тащит все файлы которые разработчик пожелает засунуть в свой пакет.
Там могут быть и исполняемые файлы и либы и медиа-ресурсы и скрипты автозагрузки.
Разве что, два разных deb-пакета не могут тащить в себе одинаковые файлы (/lib/XXX), каждый должен тащить свой собственный файл (/usr/lib/YYY/XXX)
ploop
17.06.2016 15:25В deb можно засунуть что угодно, но обычно суют ресурсы и бинарники, а остальное — да, прописывают как зависимости, а дальше пакетный менеджер их разруливает. Что есть правильно, следуя этой идеологии, и лучше их не трогать.
bemyak
17.06.2016 12:52Вот тут один из мэйнтейнеров ArchLinux выступает с критикой snap-пакетов:
kmkeen.com/maintainers-matter/2016-06-15-11-51-16-472.html
Перевод основных положений на опеннете:
www.opennet.ru/opennews/art.shtml?num=44611
Просто для расширения кругозора, и возможности посмотреть на ситуацию с позиции авторитетного специалиста :)
severgun
17.06.2016 14:22+5Сколько же ненависти в Linux сообществе. Каждый первый бородатый и готов мать продать за идейность и непоколебимость.
Места им жалко. А времени и нервов вам не жалко когда приложение А и Б требуют разные версии одной библиотеки в системе? Или сооружение подпорок и мостов из костылей уже в крови? Под каждый чих самолично собирать докер контейнеры. Ммммм… удовольствие.
А в изолированных от интернета окружениях вы пробовали ставить пакеты не из главного репозитория? Вкусно?leggiermente
17.06.2016 15:09Согласен:
1. Установка старого приложения в новой системе / нового в старой системе;
2. Установка пакетов без интернета
обуславливают использование снэпов.
Во всех остальных случаях вижу лишь минусы перед пакетными менеджерами, начиная от безопасности (не могу согласиться с тезисом из статьи) и отступлениями от гайдлайнов системы, кончая увеличением использования ресурсов.
Кто часто использует два указанных кейса, пожалуйста переходите на снэпы. Но когда этот подход продвигают крупные компании и предполагают его универсальность в будущем, при наличии удобных и надёжных работающих инструментов, это заставляет насторожиться.ploop
17.06.2016 15:28+1Во всех остальных случаях вижу лишь минусы перед пакетными менеджерами
Блин, но ведь вроде никто не собирался выпиливать пакетные менеджеры! Снепы — просто ещё один удобный инструмент, который иногда может выручить, хотя-бы время сэкономить. Что в этом плохого, чего все так испугались?
Prototik
17.06.2016 15:09А времени и нервов вам не жалко когда приложение А и Б требуют разные версии одной библиотеки в системе?
Вот ни разу не было такой проблемы. Зависит от дистра. Обычно этим страдают deb дистры.
Под каждый чих самолично собирать докер контейнеры. Ммммм… удовольствие.
Это я вообще отказываюсь комментировать.
А в изолированных от интернета окружениях вы пробовали ставить пакеты не из главного репозитория? Вкусно?
Да нормально, более того — обычно так и делаю. Один раз выкачиваю пакет и все нужные ему пакеты и ставлю их все скопом. Где проблема тут — не понимаю. Если уж совсем припрёт, то можно заставить пакетный менеджер поставить пакеты, не смотря ни на какие зависимости. Правда результат здесь уже никто и не гарантирует.daggert
17.06.2016 16:07>>Да нормально, более того — обычно так и делаю. Один раз выкачиваю пакет и все нужные ему пакеты и ставлю их все скопом.
Как это может быть удобнее выкачивания одного файла? Кроме того: Если не предполагается апдейтить — в чем вообще выигрыш?Prototik
17.06.2016 21:28Ммм… никак? Может потому, что для скачивания всех файлов мне нужно сделать ровно одно движение, как и для одного файла? Если не предполагается апдейтить — не апдейтите, в чём пробелема?
vanxant
17.06.2016 19:35Это если у вас весь софт из дистра.
Когда делаешь пару шагов в сторону (одна прога проприетарная, вторая самописная, третью скачали с заброшенной репы на гитхабе), и их нужно поженить в рамках одной оси — вот тут-то и настаёт День Бубна.tsukasa_mixer
17.06.2016 20:43+1Что мешает для мамонтов подготовить пещеру в которой будет весь этот зоопар жить?
Для заброшенных реп вам в любом случае придется настраивать окружение для сборки и собирать все обособленно от системы.
Для самописно — что мешает тупо держать в актуальном состоянии ??? Бибилиотеки редко меняются беспричинно с поломкой всех совместимостей, обычно это означает мажерное обновление, зачастую всей системы. Никтож не жалуется что у людей не получается запустить на 10 mac OS файлы от 8й…
Вобоще почитав комментарии складывает чувство что большинство просто старательно и прицельно стреляют себе по ногам из ружей…
т.е. стараются создать сами себе проблемы.
Да понятно бывают случаи когда надо дружить слабо совместимые вещи, но для этого и придумали изоляцию окружения уже черти знает сколько времени…
все жалуются на то что к репам доступа не будет, хотя никто им не мешает использовать образы репозиториев для локального хранения…
Было-бы желание — найдется инструмент, а так — лень с помесью безумия.
Подобые изолированные пакеты полезны будут в следующих случаях
— редкий огорожденный софт, который никто не собирается поддерживать.
— билды софта для демонстраций (альфы, беты, превью)
больше я незнаю нафига это нужно, весь остальной софт имхо должен нормально работать с репозиториями, это стандартный механизм, боле менее гарантирующий совместимость внутри текущего релиза + позволяющий адекватно использовать функционал библиотек стандартной поставки и не засорять мусором систему.
Prototik
17.06.2016 21:29Такой софт всё ещё собирается в пакеты, никаких отличий от системных там нет. Да и редко такие встречаются, если честно. На кой фиг мне нужен древний софт?
wmtoolsnet
17.06.2016 21:46+1На кой фиг нужно реинсталлить\обновлять всю систему ради одной программы, которая тянет либу из testing?
Prototik
17.06.2016 22:43Ну так и качайте только одну либу из testing, кто запрещает то? Чего вы сами себе проблемы выдумываете?
wmtoolsnet
18.06.2016 12:16Проблема в том, что та либа тянет за собой еще кучу всякого дерьма из testing.
Prototik
18.06.2016 12:20В Snap пакете всё-равно потребуется эта либа и её зависимости, т.е. выкачивать примерно один объём данных. Где профит то, или какая-то проблема?
wmtoolsnet
19.06.2016 13:28Почему это примерно один?
Установка GIMP'a потянет за собой выкачивание пол-Гнома.
Установка Cheese тоже потянет за собой выкачивание пол-Гнома.
Однако если я установлю Cheese после GIMP'a (а равно как после многих других, более обязательных программ), мне потребуется выкачать всего 5 мегабайт.
И я пытаюсь понять, придется ли ради каждой программы выкачивать ВСЕ ее зависимости?Prototik
19.06.2016 18:20Ну мы ведь разговаривали про несовместимые версии библиотек, т.е. каждому приложению в любом случае свои «пол гнома», а откуда их брать — из репозитория или из snap пакета тут роли не играет, качать примерно одинаково.
wmtoolsnet
17.06.2016 21:40Прочитал заголовок статьи. Думал очередное изобретение Потеринга. Ан-нет, ошибся.
Не совсем понимаю целесообразность этих телодвижений. И во что это выльется в системе в итоге. Если после установки пакета у меня будет каталог что-то типа /usr/software/uber_soft/ с бинарником и либами внутри папки — то я согласен, это будет круто. Думаю можно будет написать скрипт, который прошарится по диску, найдет одинаковые либы, и сделает вместо их всех, симлинки на один экземпляр.
Но если это будет в стиле «скинем все в /usr/lib, дадим номер версии, в зависимостях не пропишем, а там пусть юзер сам учится удалять, и вообще это опенсорс, не нравится — не пользуйтесь и прочее бла бла бла» — то пожалуй это возненавидят еще больше чем systemd.
Как по мне, в никсовом мире, есть масса более актуальных проблем. Например допилить наконец вменяемый графический сервер (привет, Mir), перепилить IO-стек (сижу на NVMe 2.5Gb read, 1.4 Gb write, а быстрее не стало, в отличие от Винды), разобраться с поддержкой оборудования. Нет, страдают херней.
zim32
17.06.2016 22:31-2npm так и работает. Удобно, не боишься что установка очередной библотеки приведет к конфликту версий или еще чему-то. А главное что каждая версия библитеки протестирована на конкретных версиях зависимостей.
tsukasa_mixer
20.06.2016 13:47знаете, npm это просто маленький филиал ада, давайте не будет его тут расковыривать а том думгая придется звать…
zim32
20.06.2016 14:05Если так подумать все пакетные менеджеры — это ад. У одних одни проблемы у других проблемы другого рода. Так что давайте не преувеличивать. Ну или напишите свой идеальный пакетный менеджер
Massacre
20.06.2016 14:36Как действительно работает NPM можно узнать примерно здесь — https://habrahabr.ru/post/280039/
tsukasa_mixer
20.06.2016 16:14И да и нет, понятно что у любого механизма есть та или иная проблема. Но лично у меня мозоль с языка не сходит от мата что я несу когда приходится работать с данным пакетным менеджером. Тяжелый, медленный, проблемы зависимостей, удаление старых версий модулей которые ты использовал гдет.
Все чаще посещаю мысли избавится от него нафиг.
Al_Azif
18.06.2016 03:56-2Кто-то наконец включил мозги и решил наконец выйти из этого тупика, сделать так чтобы софт работал в любом дистре, независимо от степени кривизны разрабов и дистров и софта. Теперь осталось сделать нормальный гуй и устранить исторические анахренизмы.
PS: Про GoboLinux конечно никто не слышал. Там это решено на уровне fs — просто и элегантно. Практически как на маке.
ColorPrint
18.06.2016 14:22Распространяются они только напрямую, без использования репозиториев?
И как в том же Arch например с ними работать?
mwizard
19.06.2016 03:43Я сейчас задам глупый, нубский вопрос, но тем не менее прошу дать на него умный ответ. Тут очень многие пишут о dependency hell, перезаписи системных библиотек разными версиями и других неудобствах, которые влечет за собой нынешняя система зависимостей.
Я хотел уточнить — я правильно понимаю, что нынешний подход динамического линковщика к поиску зависимых библиотек абсолютнейше не включает в себя semver? Другими словами, если в
/usr/lib/естьlibfoo-1.0.4.so,libfoo-1.9.soиlibfoo-2.0-rc1.so, а программе нуженlibfoo-1.so, то ей не загрузятlibfoo-1.9.soавтоматически? Или, например, если нуженlibfoo-1.0.3.so, то не будет предложенlibfoo-1.0.4.so?
Если так, то, может, решать проблему нужно с другого конца?
Prototik
19.06.2016 18:26Нынешний подход линковщика учитывает semver — но ровно до тех пор, пока автор всё не сломает.
Т.е. есть приложение app, которые слинковано с libfoo.so.1, который есть симлинк на libfoo.so.1.2, который есть симлинк на libfoo.so.1.2.3. Выходит апдейт библиотеки libfoo — и у нас теперь есть libfoo.so.1.3, который есть симлинк на libfoo.so.1.3.0. Приложение продолжает работать, т.к. ссылка libfoo.so.1 обновилась и указывает на libfoo.so.1.3 и линковщик вполне себе справляется. Конечно, если автор не выкинул из это библиотеки половину функций, которые использует app.
Но в один прекрасный день выходит libfoo 2, и теперь у нас такая иерархия: libfoo.so -> libfoo.so.2 -> libfoo.so.2.0 -> libfoo.so.2.0.0. Но приложение то слинковано с libfoo.so.1! Нужная либа не находится и приложение не запускается.
Предвидя вопрос «А почему нельзя просто линковаться с libfoo.so, который будет хоть указателем на libfoo.so.100500» — смена первой цифры нумерации версии обычно подразумевает тотальную смену api, т.е. приложение в любом случае не запустится.mwizard
20.06.2016 04:51+2Но приложение то слинковано с libfoo.so.1! Нужная либа не находится и приложение не запускается.
Скорее, возникает вопрос "а куда делась so.1, ведь это разные версии API, и пакетный менеджер знает, что so.1 еще используется в таком-то пакете, следовательно, его нельзя удалять и это должна быть side by side установка".
В принципе, несмотря на некоторые ограничения по сравнению с полным semver (например, невозможность указать диапазон допустимых версий для линковки), описанная вами схема вполне рабочая.
Мысли вслух — если у нас естьlibfoo.so.1.2.3, то после установкиlibfoo.so.1.3.0, приложения, которым было важно сохранить точную версию, продолжают использоватьlibfoo.so.1.2.3, а тем, кому была важна мажорная версия API, будет загруженlibfoo.so.1.3.0через симлинк сlibfoo.so.1. Все выглядит достаточно логичным, от менеджера пакетов требуется только понимать, какая версия используется в каком бинарнике и не удалять старые версии, если они где-то используются явно.
Но теперь я не понимаю, почему в принципе идут разговоры "о ужас, в linux есть dependency hell! кошмарный dll hell, как в windows!"? Если множество разных версий библиотек могут спокойно уживаться вместе — в чем в принципе тогда были предпосылки для создания snap-пакетов?tsukasa_mixer
20.06.2016 13:50MAC style
mwizard
20.06.2016 14:13Нет, с чего вы взяли?
В OS X есть две разных семантики библиотек. Одна — .dylib, полностью аналогична .so в Linux, и страдает от тех же проблем.
Вторая — бандлы фреймворков [1][2], в которых используется семантическое версионирование, параллельная установка, динамическая выгрузка (в отличие от
dlclose, который на самом деле не обязан ничего выгружать — и не выгружает), и всякое такое.
На маках есть свои проблемы, но dependency hell среди них нет.
tsukasa_mixer
20.06.2016 15:37нет, я про методологию установки.
>> dependency hell среди них нет.
Но есть проблема с мусором который остается от пакетов и невозможностью нормального удаления пакетов, в виду отсутсвия механизма удаления библиотек.
у них не dependency hell а dependency limb )))mwizard
20.06.2016 15:41Остается, да. Но это не отсутствие механизма удаления библиотек, а отсутствие встроенного пакетного менеджера. Можно, конечно, через
pkgutil --files com.teamviewer.teamviewer10смотреть, что и куда установлено, и удалять руками… А можно пользоваться homebrew, macports и иже с ними, которые более-менее решают эту проблему для софта из репозиториев. Возможно, есть решения и для чистого удаления сторонних .pkg-шек, но я не искал.isden
20.06.2016 15:54Что-то сдается мне, что написать простейшую обертку над pkgutil --pkgs / pkgutil --files — это дело элементарное. Странно, что в дефолтной макоси этого нет.
mwizard
20.06.2016 15:58Проблема в скриптах пре- и пост-установки, которые могут быть в pkg (ради которых pkg и делают, собственно), причем скрипты не обязательно написаны на shell — это могут быть вообще произвольные бинарники, внутрь которых заглянешь только дизассемблером. Поэтому в общем случае макось не знает, что они творят, и в --files не вносит. Как вариант, решается это виртуализацией процесса установки, чтобы перехватить все операции над ФС и defaults, но в Apple по какой-то причине не стали заморачиваться. Может быть, кто-то заморочится?
isden
20.06.2016 16:01С виртуализацией тут вот такая проблема есть — некоторый софт ставит ядерные модули, например. А другому нужен доступ ко всяким низкоуровневым API. Я уже тоже подумывал про встроенный механизм песочницы/контейнеров, но поковырявшись пару вечеров с заведением скайпа там — плюнул на это дело.
mwizard
20.06.2016 16:05Ну, чисто теоретически, опять же, можно поверх mach нахреначить гипервизор… Позаворачивать все сисколлы на гипервизор, а оттуда в юзерспейс перекидывать лог действий. Но у меня что-то руки немного опускаются от перспектив подобных извращений — причем я даже не уверен, не работает ли ядро УЖЕ на -1 кольце, или не занимают ли его проги типа Parallels. Вроде ведь как делать цепочки гипервизоров пока нельзя?
tsukasa_mixer
20.06.2016 16:36Да. я как-бы о том-же.
Решения нет — я искал, ужасался.
честно говоря подобное немного ставит в ступор, непонятна позиция apple.
Из действенных — ставить из псевдорепозиториев — homebrew, macports.mwizard
20.06.2016 18:02Да не псевдо они, вполне настоящие — как минимум, homebrew. С макпортами плотно не работал, за них сказать не могу. Или почему вы их "псевдо" считаете?
А по поводу решения — может, раз уж Эппл пошла копать в направлении сэндбокса системы, то в 10.12 будет песочница для произвольных приложений? Сейчас песочницы для приложений из стора уже есть, но толку от них.
tsukasa_mixer
20.06.2016 18:23А толку, песочница песочнийцей, но больше всегда интересовала работа с пакетами, а там все плохо.
Да и всеравно это не решит проблему взаимосвязи приложений, только еще больше может раздуть дистрибьютивы приложений (вообще в маке на мой взгляд самый большие дистрибьютивы, т.е. блокнот весящий 100мб это вполне норимально для мака)
mwizard
20.06.2016 16:02А, ну и стоит отдельно отметить, что пакетные менеджеры в Линуксе, например, не ведут учет файлов, которые были созданы после того, как пакет был установлен. Поэтому если пакет не говорит, как именно его деинсталлировать, этот мусор останется висеть.
С программами в Windows та же ситуация — если деинсталлятор предпочтет что-то оставить в системе (какую-то расшаренную библиотеку, или лицензионную информацию) — он их оставит.
Маки в этом плане не исключение.
tsukasa_mixer
20.06.2016 16:39с Linux на самом деле все понятно, да мусорят все, в той или иной мере, но чаще всего мусор образуется в home/ папке, в корне все старые пакеты стараются описывать файлы и папки которыми они оперируют и проблем в будущем не создают.
Впрочем всегда найдутся исключения.mwizard
20.06.2016 18:04ха… если бы. Всякие скрипты конфигурирования пост-установки срут и в /etc, и в /var, и демонов прописывают, и чужие конфиги меняют… А потом удаляешь пакет, и оказывается, что какой-нибудь nginx делал include какого-нибудь hhvm, и приехали.
tsukasa_mixer
20.06.2016 18:20ну всегда найдется частный случай. идеала увы не достичь.
Сейчас хотяб все нормально прибрано.
Vilgelm
20.06.2016 05:56Вот не кажется мне это хорошей идеей. Притащили инсталляторы из Windows, хотя для меня одним из серьезных преимуществ Linux является как раз установка из репозиториев. Это в разы удобнее поисков и выкачиваний инсталляторов, а еще не приходится задумываться, что вот этот инсталлятор притащит с собой еще какой-нибудь Mega System Boost Registry Cleaner 10.1 и еще пару адварь. А так многие могут теперь забить на добавление софта в репозитории и привет mail.ru агенты еще и на Linux. И зачем?
creker
20.06.2016 11:18А то deb не может с собой ничего притащить. Запросто это сделает и никто ничего не заметит, если не ковырять весь deb пакет. А т.к. из под рута запускаем, то успешно установит все, что ему вздумается. Нет никакой принципиальной разницы в том, чтобы качать инсталлятор с сайта или с репозитория. Репозиторий это тот же сайт, который просто напросто понятен консольной утилите. Точно так же нужно искать репозитории, если нужно что-то поставить. Особенно свежую версию софта. Как то nginx или docker, которые в ubuntu trusty у меня качались старых версий. И тем более, если софт вообще не входит в стандартный набор.
RiseOfDeath
Вот бы еще снэпы запускались бы в изолированом окружении.
Galiaf47
Могли бы запускаться, вы имели в виду?
RiseOfDeath
Да, разумеется.
Главное что такая фича нужна «из коробки».
GamePad64
Они вроде имеют поддержку AppArmor. А полная изоляция (как в docker и lxc) не сильно нужна десктопным приложениям, ибо ломает их интеграцию. Попробуйте, например, запустить Qt-приложение в docker-контейнере с системным стилем виджетов.
isden
Ну еще, при желании, можно через systemd ограничить доступ куда не нужно.