Комментарии 167
Вот бы еще снэпы запускались бы в изолированом окружении.
А снэпы статически слинкованы со своими зависимостями? Т.е. на гольном ядре или в пустом образе докера их запустить можно?
Кароче, прощяй экономия места… То мы выкачивали гиг зависимостей только один раз, а теперь будем качать этот гиг каждый раз вместе с новой программкой, которая сама по себе может даже и мегабайта не весить…
Вот тоже самое хотел сказать.
ИМХО: Это жуткий шаг не туда. Многие сторонники линукса ставят во главу угла то что библиотеки для зависимостей не надо качать для каждой программы, а тут предлагают типичный для некоторых виндоузовских программ сценарий — возьмем все и сольем в один exe-шник.
ИМХО: Это жуткий шаг не туда. Многие сторонники линукса ставят во главу угла то что библиотеки для зависимостей не надо качать для каждой программы, а тут предлагают типичный для некоторых виндоузовских программ сценарий — возьмем все и сольем в один exe-шник.
Так одно другого вроде не исключает. Или есть причины по которым может быть Snap, но не может быть привычного варианта?
Я боюсь говнокодеров, которые станут игнорировать репозитории. Я боюсь админов-даунов, которые работают под рутом и не смогут вовремя понять что устанавливаемый ими «пак» скомпрометирован.
Да. Примерно такая же, по которой может быть ppa, но в официальные репозитории пакет никто даже не пытается протолкнуть. Вангую, что теперь будем иметь кучу софта, которому даже ppa заводить не будут.
Так вас же никто насильно не заставляет их использовать. Но в некоторых случаях это может быть очень удобно, особенно когда возникает конфликт версий зависимостей (одной софтине нужна одна версия библиотеки, другой — другая). Такое может быть при установке нового софта на старую систему или наоборот.
Разрулить можно, но это тот ещё квест.
Разрулить можно, но это тот ещё квест.
>Так вас же никто насильно не заставляет их использовать.
Ну, это пока…
Ну, это пока…
Так может надо решить проблему того, что это то ещё квест?
Я не знаю, как это делается, но если в системе так сложно запустить бинарник с теми либами, которые я хочу, а не теми, которые хочет система, то что-то в системе не так.
Я не знаю, как это делается, но если в системе так сложно запустить бинарник с теми либами, которые я хочу, а не теми, которые хочет система, то что-то в системе не так.
Так эти нужные либы 1) надо найти отдельно, 2) суметь запустить с ними бинарник. Всё это можно с помощью гугла и такой-то матери, но это я и назвал квестом.
За что минус?
1) Разве нельзя выкачать произвольную версию бинарника либы из системного репозитория?
2) Если кто-то распространяет бинарники без описания зависимостей, то это вроде не системы проблема.
1) Разве нельзя выкачать произвольную версию бинарника либы из системного репозитория?
2) Если кто-то распространяет бинарники без описания зависимостей, то это вроде не системы проблема.
Минус не мой, не имею привычки минусовать обычную дискуссию, при том интересную.
1) Можно.
2) Зависимости есть, но прога А требует foo.lib версии 1.01, а прога Б требует foo.lib версии 1.05, то есть какую-то придётся выкачивать и класть отдельно, запуская бинарник именно с ней. А чтобы потом всё так и работало — скрипт запуска сочинять.
Может как-то и проще можно, я не эксперт в линуксах, просто пользователь.
1) Можно.
2) Зависимости есть, но прога А требует foo.lib версии 1.01, а прога Б требует foo.lib версии 1.05, то есть какую-то придётся выкачивать и класть отдельно, запуская бинарник именно с ней. А чтобы потом всё так и работало — скрипт запуска сочинять.
Может как-то и проще можно, я не эксперт в линуксах, просто пользователь.
1а) В стандартном репозитории убунты / дебиана для каждого пакета доступна только последняя версия. Выбирать не из чего.
В сторонних может быть лучше — в собственных репах nginx, mysql, mongodb, postgresql выложены почти все выпуски лет за 5 — 10.
1б) Устанавливать несколько версий одной библиотеки apt не умеет вообще. При конфликтах всё как в Горце: «остаться должен только один».
Вроде в генту, с её любовью к сборке из исходников, можно и несколько версий одной библиотеки держать, но это сложно, а запаковать в один блоб — просто.
apt-cache policy libcryptsetup4
libcryptsetup4:
Установлен: 2:1.6.6-5
Кандидат: 2:1.6.6-5
Таблица версий:
*** 2:1.6.6-5 0
500 mirror.yandex.ru/debian jessie/main amd64 Packages
100 /var/lib/dpkg/status
В сторонних может быть лучше — в собственных репах nginx, mysql, mongodb, postgresql выложены почти все выпуски лет за 5 — 10.
1б) Устанавливать несколько версий одной библиотеки apt не умеет вообще. При конфликтах всё как в Горце: «остаться должен только один».
Некоторые пакеты невозможно установить. Возможно, вы просите невозможного...)))
пакеты, имеющие неудовлетворённые зависимости:
libabw-0.1-1v5: Конфликтует: libabw-0.1-1 но 0.1.1-4 будет установлен
libsidplay2v5: Конфликтует: libsidplay2 но 2.1.1-15 будет установлен
Вроде в генту, с её любовью к сборке из исходников, можно и несколько версий одной библиотеки держать, но это сложно, а запаковать в один блоб — просто.
А вот лучше бы была возможность программе из депенденси ставить именно те библиотеки, которые конфликтуют, себе в закрытый sandbox, вместо перезаписывания системных и использовать именно их. Обошлись бы «малой кровью».
Кроме того, так как все они потенциально используют разные версии библиотек, будет чудовищный перерасход RAM, так как не будет работать расшаривание в памяти страниц библиотек (каждая программа из данного типа пакетов будет загружать в память свою копию glibc и всех остальных библиотек).
Если дисковое место можно особо не экономить — его в последнее время более чем достаточно, то оперативной памяти никогда много не бывает.
Если дисковое место можно особо не экономить — его в последнее время более чем достаточно, то оперативной памяти никогда много не бывает.
А такая тенденция и уже в проприетарном софте есть. Ide jetbrains, например, поставляется с Java внутри, да есть пакеты без, но главное чтобы в вашем дистрибутиве стояла не устаревшая джава. От Synology поддерживаю пакеты в Archlinux аналогично qt либы лежат внутри, и они не заменяемы с хост системными, толи версия толи патчи какие. Ср**ый upwork клиент тоже веду пакет, тот еще гемор делать это, софт ужаснейщий, в дистрибутиве обновился nss а ему нужен старее, а новый nss нужен другому софту, пришлось снова извращаться(с ним часто сюрпризы) Так что я за то чтобы проприетарные производители распространяли софт не только для deb а в универсальных пакетах, потому что из deb портировать на другой дистрибутив не всегда легко.
НЛО прилетело и опубликовало эту надпись здесь
Вы чет совсем не в ту степь. Именно приложения выводят Windows на текущий уровень, пока их пишут, ею пользуются и снова пишут приложения.
Пока приложений в линуксах аналогичных нет и их не пишут — говорить не о чём.
Пока приложений в линуксах аналогичных нет и их не пишут — говорить не о чём.
«Вендекапец — апокалиптическое событие, обозначающее смерть операционной системы Microsoft Windows или банкротство Microsoft. Чаще всего предсказывается линуксоидами и анонимными аналитиками с ЛОРа.
…
Пророчества о наступлении вендекапца появлялись после выхода ReactOS 1.0, Bolgenos 1.2, Wine 1.0, Слаки 13.0 и ядра линукса 4.0.» © Лурк
…
Пророчества о наступлении вендекапца появлялись после выхода ReactOS 1.0, Bolgenos 1.2, Wine 1.0, Слаки 13.0 и ядра линукса 4.0.» © Лурк
Причём тут? Во-первых, у Windows уже давно есть своё решение проблемы библиотек (требуемую версию в каталог к EXE или, как вариант, в winsxs), а во-вторых да, систему определяют приложения, а не наоборот.
PPA можно использовать и в Debian 8+ (поднять свой репозиторий для дебиана — это так слооожно).
Беспроблемная работа драйверов на 2.6.32, никогда не падающие Иксы и многое другое в очередном маркетинговом буллшите от Каноникал!
Беспроблемная работа драйверов на 2.6.32, никогда не падающие Иксы и многое другое в очередном маркетинговом буллшите от Каноникал!
Да хавно этот ваш Каноникал, хавно Винда и МакОсь, Дебиан — расово верный дистрибутив. Пожалуй, ужаснее срача виндузятников и линуксоидов может быть только срач между линуксоидом и линуксоидом (у кого дистрибутив круче).
Выбор дистрибутива — личное дело и личные проблемы.
Когда кто-то анонсирует новую убертехнологию и агитирует за её использование — ничто не мешает мне агитировать против её использования.
I.e когда 2 snap-приложения зависят от взаимоисключающих параметрах ядра — одно не заработает; когда snap-приложение не сможет в установленный X сервер — оно его уронит или не запустится.
Когда Red Hat в каждой второй публикации половину займет рассуждениями о проблемах бездомных кенгуру в Нигерии, я буду писать о том, что кто-то сошёл с ума.
Когда кто-то анонсирует новую убертехнологию и агитирует за её использование — ничто не мешает мне агитировать против её использования.
I.e когда 2 snap-приложения зависят от взаимоисключающих параметрах ядра — одно не заработает; когда snap-приложение не сможет в установленный X сервер — оно его уронит или не запустится.
Когда Red Hat в каждой второй публикации половину займет рассуждениями о проблемах бездомных кенгуру в Нигерии, я буду писать о том, что кто-то сошёл с ума.
Ubuntu не заменяли традиционные deb пакеты snap'ами, они дополнили традиционные deb альтернативой, которая может иметь свои преимущества и недостатки. Из плюсов:
Пока ярые фанатики считали килобайты установочных составляющих, Windows положила на это болт и выпускала приложения от десяток до сотен мегабайт. Когда интернет был 64 Кб/с а жесткий диск — 504 МБ это было бы проблемой, но сейчас скорость у многих под 100 Мб/с (не у всех, конечно, но скорость интернета увеличилась на порядки) и даже на бюджетниках уже можно найти под 1ТБ жесткий диск. Соответственно, один из главных недостатков нивелируется — сейчас многим наплевать, сколько весит инсталлятор. Если он даёт определенные преимущества разработчикам и пользователями — пусть будет, пусть вообще везде будет, где может быть. Ну а относительно того, что им могут заменить deb — в OpenSource всегда можно всё поправить, разработчики не обладают монополией и каждый может поменять дистрибутив на свой вкус, этим и славятся дистрибутивы Linux.
Ваш же комментарий не несёт никакой здравой критики или информации, вы просто сказали, что Debian рутой, а маркетинг Каноникал вам не по душе. Причём тут всё это?
Использование формата snap позволит разработчикам Ubuntu значительно быстрее создавать пакеты с новыми версиями рабочих окружений или прикладных программ. Особенность формата ещё и в том, что устанавливаемое с их помощью ПО изолировано от системы и не оказывает на неё никакого влияния. Подобная схема значительно более надёжна и безопасна.
Пакеты snap обладают определёнными преимуществами для программистов, создающих прикладное ПО для настольных машин, серверов, мобильных устройств или IoT. Единый инструмент избавит их от необходимости применять виртуальную среду для написания и тестирования приложений.
Разработчикам платных программ больше не потребуется отслеживать все зависимости и совместимости с различными системными библиотеками, что особенно актуально для старых версий Ubuntu. По этой причине Canonical планирует убедить программистов перевести все подобные решения из deb в snap уже осенью текущего года, тем более что их интерес тут также очевиден.
Вместе с этим, не может быть и речи про отказ от deb. Соответствующие пакеты будут поддерживаться, в том числе и в Ubuntu 16.04, чтобы быть доступными для всех желающих.
источник
Пока ярые фанатики считали килобайты установочных составляющих, Windows положила на это болт и выпускала приложения от десяток до сотен мегабайт. Когда интернет был 64 Кб/с а жесткий диск — 504 МБ это было бы проблемой, но сейчас скорость у многих под 100 Мб/с (не у всех, конечно, но скорость интернета увеличилась на порядки) и даже на бюджетниках уже можно найти под 1ТБ жесткий диск. Соответственно, один из главных недостатков нивелируется — сейчас многим наплевать, сколько весит инсталлятор. Если он даёт определенные преимущества разработчикам и пользователями — пусть будет, пусть вообще везде будет, где может быть. Ну а относительно того, что им могут заменить deb — в OpenSource всегда можно всё поправить, разработчики не обладают монополией и каждый может поменять дистрибутив на свой вкус, этим и славятся дистрибутивы Linux.
Ваш же комментарий не несёт никакой здравой критики или информации, вы просто сказали, что Debian рутой, а маркетинг Каноникал вам не по душе. Причём тут всё это?
Я правильно понял, что snap-пакеты — это аналог инсталляторов Windows?
Если так, то новость замечательная, отсутствие нормальных инсталляторов — пожалуй, главное, что меня уже который год удерживает от ухода с Windows на Linux.
*собрался читать про Snap подробнее*
Если так, то новость замечательная, отсутствие нормальных инсталляторов — пожалуй, главное, что меня уже который год удерживает от ухода с Windows на Linux.
*собрался читать про Snap подробнее*
Эээ… А за что минус? Если я не прав — поясните подробнее, пожалуйста, мне действительно интересно.
На площадке хабра не принято хвалить windows. Любые намеки на то что «запустил консоль → ввел непонятные команды для подключения ppa → ввел apt-get» неудобны конечному пользователю — караются непониманием.
PS: Я под защитой убунты!
PS: Я под защитой убунты!
А, ясно.
Нет, я ничего не имею против консоли. Я только хочу и дальше иметь папочку, в которой лежат stand-alone инсталляторы, которыми можно пользоваться самому и давать знакомым вне зависимости от состояния репозиториев.
А будут эти инсталляторы запускаться из-под консоли, или из GUI — мне, в общем, плевать.
Нет, я ничего не имею против консоли. Я только хочу и дальше иметь папочку, в которой лежат stand-alone инсталляторы, которыми можно пользоваться самому и давать знакомым вне зависимости от состояния репозиториев.
А будут эти инсталляторы запускаться из-под консоли, или из GUI — мне, в общем, плевать.
Я давеча обнаружил удивительную штуку, для себя, appimage. Все в одном. Уж больно меня бесит тащить Qt в свой elementary.
Ага, посмотрю, спасибо.
Но я где-то год назад пытался найти способ использовать инсталляторы (и, вроде, изучил все существующие варианты) — пришёл к тому, что все существующие решения слишком кривы, чтобы использовать их для установки всего ПО в системе.
Хочется верить, что появление нативной поддержки snap-пакетов решило эту проблему.
Но я где-то год назад пытался найти способ использовать инсталляторы (и, вроде, изучил все существующие варианты) — пришёл к тому, что все существующие решения слишком кривы, чтобы использовать их для установки всего ПО в системе.
Хочется верить, что появление нативной поддержки snap-пакетов решило эту проблему.
Т. е. одну копию qt на всех тащить бесит, а по qt на каждое приложение — не бесит, ок.
Перестаньте этого хотеть.
Как часто ваши stand-alone-инсталляторы обновляются? Сколько у вас в той папочке уже скопилось уязвимостей, в том числе RCE — никому неведомо. Благодаря этим уязвимостям часть инсталляторов в той папочке уже, возможно, чем-то заражена. И это не считая того, также замечательного, факта, что вы устанавливаете на свой компьютер ПО, взятое вашим приятелем не пойми откуда, возможно, с троянами и прочей нечистью, вместо того, чтобы взять проверенную версию из ненадёжного источника.
Делайте, что хотите, на Windows, но не тащите этот мусор в GNU/Linux, позязя!
P. S. И не рассказывайте, пожалуйста, про антивирусы. Антивирусы — это последнее прибежище безысходности.
Как часто ваши stand-alone-инсталляторы обновляются? Сколько у вас в той папочке уже скопилось уязвимостей, в том числе RCE — никому неведомо. Благодаря этим уязвимостям часть инсталляторов в той папочке уже, возможно, чем-то заражена. И это не считая того, также замечательного, факта, что вы устанавливаете на свой компьютер ПО, взятое вашим приятелем не пойми откуда, возможно, с троянами и прочей нечистью, вместо того, чтобы взять проверенную версию из ненадёжного источника.
Делайте, что хотите, на Windows, но не тащите этот мусор в GNU/Linux, позязя!
P. S. И не рассказывайте, пожалуйста, про антивирусы. Антивирусы — это последнее прибежище безысходности.
Err, typo. «Из надёжного источника», конечно же. Поторопился, чтобы успеть исправить за 3 минуты :-(
Да это прямо FUD какой-то, если не из репозитория — значит, обязательно с вирусом. Конечно, приходится проверять и обновлять вручную, зато и зависимости от внешних источников нет. И в случае глюков свежих версий можно от них отказаться до исправления…
Да это прямо FUD какой-то, если из репозиториев — значит, обязательно какая-то зависимость и якобы нельзя за`hold`ить пакет.
Зависимость — только от официальных репозиториев ОС, если они накроются, то всё равно надо бежать с этой ОС подальше. И почему нельзя отказаться от какого-то определённого обновления, мне тоже непонятно.
Зависимость — только от официальных репозиториев ОС, если они накроются, то всё равно надо бежать с этой ОС подальше. И почему нельзя отказаться от какого-то определённого обновления, мне тоже непонятно.
Это один из принципов Linux — понимай что делаешь, а не твори магию, как в винде. Если творишь магию и тебе это неудобно — ССЗБ.
Вы однобоко смотрите на ситуацию.
Чем отличается установка нужной мне программы из стороннего репозитория (я на 12.04 сижу и мне не обновится просто так) и установка заранее подготовленного инсталляционного пакета с сайта производителя? Я не буду говорить о зависимостях, сделаем вид что их нет. Есть просто ppa от производителя и его-же deb выложенный на сайте. Где разница?
Отвечу вам сам-же: Ее нет. Если производителя скомпрометирует хакер Вася, то я точно так-же получу завирусованный пакет. Разницы никакой.
Про магию мне немного смешно: Что вы подразумеваете под ней? Я под windows всегда ставлю то что знаю куда и как поставится. Я качаю установщики для программ с сайтов-производителей, по возможности это портейбл-версии, и как-то ни разу не было проблем с вирусами, мейлру крапом или «магией».
И да: Я всегда понимаю что я творю в своем дистрибе и стараюсь все свести все к минимализму, в том числе наличие сторонних библиотек и демонов.
Чем отличается установка нужной мне программы из стороннего репозитория (я на 12.04 сижу и мне не обновится просто так) и установка заранее подготовленного инсталляционного пакета с сайта производителя? Я не буду говорить о зависимостях, сделаем вид что их нет. Есть просто ppa от производителя и его-же deb выложенный на сайте. Где разница?
Отвечу вам сам-же: Ее нет. Если производителя скомпрометирует хакер Вася, то я точно так-же получу завирусованный пакет. Разницы никакой.
Про магию мне немного смешно: Что вы подразумеваете под ней? Я под windows всегда ставлю то что знаю куда и как поставится. Я качаю установщики для программ с сайтов-производителей, по возможности это портейбл-версии, и как-то ни разу не было проблем с вирусами, мейлру крапом или «магией».
И да: Я всегда понимаю что я творю в своем дистрибе и стараюсь все свести все к минимализму, в том числе наличие сторонних библиотек и демонов.
Я отвечал на конкретную фразу:
вне контекста snap-пакетов (которые, ИМХО, бесполезны, но вполне в стиле оказуаливания Linux'а от убунты и наверняка кому-то понравятся).
Когда ты вводишь "непонятные команды", меняешь значения регистра, которое ты понятия не имеешь на что влияет и т.д. 95% инструкций для решения проблем на Win вообще не подразумевают осознания собственных действий. Многие сисадмины решают проблемы "рецептом" из набора. Конечно некоторые делают такие инструкции и для Linux, но это как раз перенос Win-way на Lixux.
«запустил консоль → ввел непонятные команды для подключения ppa → ввел apt-get» неудобны конечному пользователю — караются непониманием.
вне контекста snap-пакетов (которые, ИМХО, бесполезны, но вполне в стиле оказуаливания Linux'а от убунты и наверняка кому-то понравятся).
Про магию мне немного смешно: Что вы подразумеваете под ней?
Когда ты вводишь "непонятные команды", меняешь значения регистра, которое ты понятия не имеешь на что влияет и т.д. 95% инструкций для решения проблем на Win вообще не подразумевают осознания собственных действий. Многие сисадмины решают проблемы "рецептом" из набора. Конечно некоторые делают такие инструкции и для Linux, но это как раз перенос Win-way на Lixux.
Процентов 100 того что я печатаю каждый день в eclipse, будет непонятно случайному обывателю. Сто процентов вещей я не пойму придя в соседний кабинет, где работают люди из не IT сферы, и уж точно на 147% я не пойму придя в бухгалтерию. Понимаете аналогию?
У меня есть рабочий линукс, так получилось что он у меня есть. Развиваться в сисадмина я не хочу, потому что а) это мне не нужно б) я не заинтересован вовсе в изучении данной темы за свое личное время в) мне за это не платят. По этому я на каждый чих активно гуглю. Некоторые проблемы решаются быстро, как например установка обычных прав на usb устройства, и я понимаю что я пишу в терминале, но иногда я месяц бьюсь головой об стену над кем-то написанным скриптом и не могу понять что там написано, как например было с компиляцией VLC под старым ядром. Я тупо взял этот скрипт и запустил, все.
Изучать его и понимать меня не заставите под дулом пистолета. Я никогда не поверю что все повально пользователи линукса изучают досконально все что они копируют с инета. Solved solution нашли → скопировали → чуток подправили → запустили. Не все линуксоиды испытывают радость от решения проблем, потому как проблема зачастую мешает им выполнить их работу, а не просто «интересная фигня».
PS: И это не перенос win-way в linux, это перенос удобства. Пользователю удобно когда запустил — работает. Если вы считаете иначе — вы лжете сами себе.
У меня есть рабочий линукс, так получилось что он у меня есть. Развиваться в сисадмина я не хочу, потому что а) это мне не нужно б) я не заинтересован вовсе в изучении данной темы за свое личное время в) мне за это не платят. По этому я на каждый чих активно гуглю. Некоторые проблемы решаются быстро, как например установка обычных прав на usb устройства, и я понимаю что я пишу в терминале, но иногда я месяц бьюсь головой об стену над кем-то написанным скриптом и не могу понять что там написано, как например было с компиляцией VLC под старым ядром. Я тупо взял этот скрипт и запустил, все.
Изучать его и понимать меня не заставите под дулом пистолета. Я никогда не поверю что все повально пользователи линукса изучают досконально все что они копируют с инета. Solved solution нашли → скопировали → чуток подправили → запустили. Не все линуксоиды испытывают радость от решения проблем, потому как проблема зачастую мешает им выполнить их работу, а не просто «интересная фигня».
PS: И это не перенос win-way в linux, это перенос удобства. Пользователю удобно когда запустил — работает. Если вы считаете иначе — вы лжете сами себе.
Процентов 100 того что я печатаю каждый день в eclipse, будет непонятно случайному обывателю. Сто процентов вещей я не пойму придя в соседний кабинет, где работают люди из не IT сферы, и уж точно на 147% я не пойму придя в бухгалтерию. Понимаете аналогию?
Именно поэтому обыватель не работает вместо вас, а вы не работаете в бухгалтерии. Понимаете аналогию?
Не все линуксоиды испытывают радость от решения проблем, потому как проблема зачастую мешает им выполнить их работу, а не просто «интересная фигня».
Для мня решение проблемы подразумевает уверенность в том, что проблема больше не появится и устранена её причина, если это возможно. Шаманство по инструкции из интернета такой уверенности не дает, и потому меня не устраивает.
Solved solution нашли → скопировали → чуток подправили → запустили.
По опыту, за пределами ubuntu-подобных таких решений без объяснения что они делают в разы меньше. по крайней мере несколько лет назад было так.
И это не перенос win-way в linux, это перенос удобства.
Нагугленное непонятное решение зачастую тянут за собой проблемы, которые неочевидны, если не понимаешь, что делаешь. Для которых гуглишь очередное решение, которое тянет…
Я никогда не поверю что все повально пользователи линукса изучают досконально все что они копируют с инета.
Я знаю немало людей, которые пользуются компьютером при помощи записанных на бумажке пошаговых инструкций, состоящих из пунктов типа "для сохранения нажми кнопку "сохранить"".
Я знаю немало людей, которые пользуются компьютером при помощи записанных на бумажке пошаговых инструкций, состоящих из пунктов типа «для сохранения нажми кнопку „сохранить“».
Однако, они им пользуются. Хорошо или плохо, но пользуются.
Линукс уже перестал быть системой «для гиков», и люди в нём просто работают. Вот у меня, например, с 2009 года нет win даже в дуалбуте, и дома, и на работе, и я впадаю в ступор, когда знакомые просят что-то помочь, так как уже забыл эту систему. А в линуксе чувствую себя гораздо комфортнее, хотя не являюсь специалистом, просто пользователь. И в случае проблем — гугл, а глубина понимания моих действий зависит от того, есть ли время или желание разобраться, если нет — то слепо «по рецепту».
>>Именно поэтому обыватель не работает вместо вас, а вы не работаете в бухгалтерии. Понимаете аналогию?
Аналогия не удачна. Моя работа — не изучать дебри линукса и разрабатывать его, моя работа делать сугубо два программных продукта под windows, вот уже 10 лет.
>>Для мня решение проблемы подразумевает уверенность в том, что проблема больше не появится и устранена её причина, если это возможно. Шаманство по инструкции из интернета такой уверенности не дает, и потому меня не устраивает.
Я был тоже так уверен, до того момента как я начал работать с x265, теперь проблемы регулярны. Про проблемы с жестким диском и sata приводом я умалкиваю.
>>По опыту, за пределами ubuntu-подобных таких решений без объяснения что они делают в разы меньше. по крайней мере несколько лет назад было так.
FreeBSD, puppy linux, QNX, FreeRTOS — выбирайте. В любом из этих вещей я пользовался «тупыми» ответами из гугла, где было ~50 строк листинга и описание на одно-два предложения.
>>Нагугленное непонятное решение зачастую тянут за собой проблемы, которые неочевидны, если не понимаешь, что делаешь. Для которых гуглишь очередное решение, которое тянет…
Кривое решение которое ты понял (как ты думаешь) но которое не правильное приводит к восстановлению бекапа который был сделан кривым решением которое ты понял (как ты думал)… и это история из практики, когда собственный бекапер посчитал что надо грохнуть весь бекап на удаленном сервере резервного хранения. До этого я думал что я знаю хоть немного баш.
>>Я знаю немало людей, которые пользуются компьютером при помощи записанных на бумажке пошаговых инструкций, состоящих из пунктов типа «для сохранения нажми кнопку „сохранить“».
И это великолепно! Я работаю в месте где из 55 человек 50 не сможет ответить какая у него ОС и что такое раскладка, однако они успешно продвигают науку, при помощи компьютера используемого как записная книжка и поисковой машины! Это и есть средний пользователь: для него компьютер лишь средство для достижения своей цели, а не сама цель. Он может быть гениальным ботаником, но ходить в шапочке из фольги потому что у него дома wifi.
Аналогия не удачна. Моя работа — не изучать дебри линукса и разрабатывать его, моя работа делать сугубо два программных продукта под windows, вот уже 10 лет.
>>Для мня решение проблемы подразумевает уверенность в том, что проблема больше не появится и устранена её причина, если это возможно. Шаманство по инструкции из интернета такой уверенности не дает, и потому меня не устраивает.
Я был тоже так уверен, до того момента как я начал работать с x265, теперь проблемы регулярны. Про проблемы с жестким диском и sata приводом я умалкиваю.
>>По опыту, за пределами ubuntu-подобных таких решений без объяснения что они делают в разы меньше. по крайней мере несколько лет назад было так.
FreeBSD, puppy linux, QNX, FreeRTOS — выбирайте. В любом из этих вещей я пользовался «тупыми» ответами из гугла, где было ~50 строк листинга и описание на одно-два предложения.
>>Нагугленное непонятное решение зачастую тянут за собой проблемы, которые неочевидны, если не понимаешь, что делаешь. Для которых гуглишь очередное решение, которое тянет…
Кривое решение которое ты понял (как ты думаешь) но которое не правильное приводит к восстановлению бекапа который был сделан кривым решением которое ты понял (как ты думал)… и это история из практики, когда собственный бекапер посчитал что надо грохнуть весь бекап на удаленном сервере резервного хранения. До этого я думал что я знаю хоть немного баш.
>>Я знаю немало людей, которые пользуются компьютером при помощи записанных на бумажке пошаговых инструкций, состоящих из пунктов типа «для сохранения нажми кнопку „сохранить“».
И это великолепно! Я работаю в месте где из 55 человек 50 не сможет ответить какая у него ОС и что такое раскладка, однако они успешно продвигают науку, при помощи компьютера используемого как записная книжка и поисковой машины! Это и есть средний пользователь: для него компьютер лишь средство для достижения своей цели, а не сама цель. Он может быть гениальным ботаником, но ходить в шапочке из фольги потому что у него дома wifi.
Лучше бы в Windows появился нормальный менеджер пакетов по типу apt или yum, а не этот ад с существующим зоопарком инсталяторов.
Каждому своё — одно другому, вроде бы, не мешает.
Люди вот вполне полноценно pacman портировали и запилили поверх него msys2, как-то не помогает. Проблема с пакетным менеджером в винде это капля в море.
Лучше бы в Linux избавились от зоопарка пакетных менеджеров. А то помимо системного пакетного менеджера каждая среда программирования норовит поставить свой собственный, ни с чем не совместимый. Все эти pip'ы, npm'ы и прочее, которые лишь создают дополнительные проблемы и конфликтуют друг с другом. И периодически приходится заниматься примерно таким шаманством:
А просто когда-то давно пакеты старых версий были установлены через dpkg, и теперь pip не может их обновить. После удаления через системный пакетный менеджер всё сразу поставится как надо…
Всё это шаманство было бы не нужно, если бы сразу все зависимости поставлялись вместе с приложением единым бандлом. Поэтому snap-пакеты могут сильно упростить жизнь, когда начинается какая-нибудь ерунда с зависимостями.
А просто когда-то давно пакеты старых версий были установлены через dpkg, и теперь pip не может их обновить. После удаления через системный пакетный менеджер всё сразу поставится как надо…
Всё это шаманство было бы не нужно, если бы сразу все зависимости поставлялись вместе с приложением единым бандлом. Поэтому snap-пакеты могут сильно упростить жизнь, когда начинается какая-нибудь ерунда с зависимостями.
Не избавятся. Потому как эти ПМы работают для питона/руста/голанга/чего-нибудь ещё. Не для линукса. И их задача — давать единый доступ к пакетам и на Windows, и на Ubuntu, и на MacOS, и на воон той кофеварке. Для решения таких косяков надо просто не пускать (условно) питоновские пакеты в DEB/PPA/whatever. Им там не место.
Это выглядит что пакет retext плохо сконфигурирован в вашем дистрибутиве, либо вы поигрались с питоновским окружением, потому что есть пакетный менеджер и паралельно глобально использовать и менять версии через pip плохо. Если нужно другое окружение питона — создайте отдельное окружение с необходимыми пакетами и версиями. Если нужно собрать пакет — указываете в зависимостях версии библиотек. И то что у вас нас скриншоте не должно происходить.
virtualenv или Docker, нет?
Уже есть, называется OneGet.
В принципе сейчас майки продвигают магазин и платформу UWP во многом из-за всевозможных инсталяторов. Там и программа попадает только в папку по сути и ничего за собой не тянет, и обновление с удалением тоже организовано средстами системы. Да и безопасность выше, если мне понадобится какая-то маленькая программа или утилита, я сначала буду смотреть в магазине.
Текущие инсталяторы в винде зло, так как они часто не следуют гайдланам, и к ним стараются кучу всего прицепить (все библиотеки и фреймворки, как мы в этом топе и обсуждаем). Из-за совместимостей и придумано альтернативное API UWP. Есть конечно с этим и проблемы, но я не думаю что в обозримом будущем винда откажется от win32 приложений.
Текущие инсталяторы в винде зло, так как они часто не следуют гайдланам, и к ним стараются кучу всего прицепить (все библиотеки и фреймворки, как мы в этом топе и обсуждаем). Из-за совместимостей и придумано альтернативное API UWP. Есть конечно с этим и проблемы, но я не думаю что в обозримом будущем винда откажется от win32 приложений.
Для гурманов есть Windows Store :) Но центральный репозиторий является одновременно и центральной точкой отказа, так что посижу я, пожалуй, со своим зоопарком локальных инсталляторов…
Побуду Кэпом. В линуксе давным давно есть пакетные менеджеры с UI.
А теперь внимание. В Windows вы тащите инсталлятор. Руками. Ставите его. Инсталлятор ставит свой обновлятор и ещё кучу мусора. Плюс ещё по копии уже установленных системных либ. Когда вам не нужно это приложение — вы сначала сносите его, а потом долго и скрупулёзно вычищаете зависимости. Руками. Это если один из инсталляторов не был криво написан — так, что валится на процедуре деинсталляции.
Теперь линукс. Вы заходите в пакетный менеджер — и ставите нужный пакет. Вам не нужно думать, что для этого пакета надо доустановить ещё Mono и Python. Когда выходят апдейты — их наличие проверяет один (!) сервис. Который вы настроили один раз. Когда вам не нужен пакет — вы через тот же интерфейс пакетного менеджера помечаете его на удаление. После чего пакетный менеджер сам (!) проверяет, какие пакеты больше никому не нужны, и предлагает их удалить за компанию.
Пишу вам как человек, который почти всю свою сознательную жизнь просидел на Windows, а на Linux перешёл прошлой осенью.
А теперь внимание. В Windows вы тащите инсталлятор. Руками. Ставите его. Инсталлятор ставит свой обновлятор и ещё кучу мусора. Плюс ещё по копии уже установленных системных либ. Когда вам не нужно это приложение — вы сначала сносите его, а потом долго и скрупулёзно вычищаете зависимости. Руками. Это если один из инсталляторов не был криво написан — так, что валится на процедуре деинсталляции.
Теперь линукс. Вы заходите в пакетный менеджер — и ставите нужный пакет. Вам не нужно думать, что для этого пакета надо доустановить ещё Mono и Python. Когда выходят апдейты — их наличие проверяет один (!) сервис. Который вы настроили один раз. Когда вам не нужен пакет — вы через тот же интерфейс пакетного менеджера помечаете его на удаление. После чего пакетный менеджер сам (!) проверяет, какие пакеты больше никому не нужны, и предлагает их удалить за компанию.
Пишу вам как человек, который почти всю свою сознательную жизнь просидел на Windows, а на Linux перешёл прошлой осенью.
Это удобно, кто же спорит?
Но:
1). Для установки зависимостей нужен интернет, который не всегда есть под рукой.
2). Для установки зависимостей нужно, чтобы эти зависимости (и сами устанавливаемые программы) всё ещё были в репозиториях, а не оказались удалены за ненадобностью. Не доверяю облакам — может быть, и зря, но я по жизни параноик.
3). Тут уже писали, что из-за использования зависимостей возникают проблемы использования нового ПО под старой системой. Для меня, любителя пользоваться десятилетней ОС и зоопарком программ разного возраста, это неприятно.
4). Что касается автообновления, то я его вообще всегда стараюсь отключать. Обновляться мне удобнее тогда, когда есть время разбираться с новшествами, читать мануалы и всё такое.
Понятно, что проблемы связаны с моим личным характером в целом и стилем использования компьютера в частности, но за всех я и не говорю.
Но:
1). Для установки зависимостей нужен интернет, который не всегда есть под рукой.
2). Для установки зависимостей нужно, чтобы эти зависимости (и сами устанавливаемые программы) всё ещё были в репозиториях, а не оказались удалены за ненадобностью. Не доверяю облакам — может быть, и зря, но я по жизни параноик.
3). Тут уже писали, что из-за использования зависимостей возникают проблемы использования нового ПО под старой системой. Для меня, любителя пользоваться десятилетней ОС и зоопарком программ разного возраста, это неприятно.
4). Что касается автообновления, то я его вообще всегда стараюсь отключать. Обновляться мне удобнее тогда, когда есть время разбираться с новшествами, читать мануалы и всё такое.
Понятно, что проблемы связаны с моим личным характером в целом и стилем использования компьютера в частности, но за всех я и не говорю.
1) Никто вам не мешает на другой машине выкачать пакет вместе с зависимостями. И поставить на целевой машине в оффлайне. К слову, под Windows онлайн-инсталляторы нынче в моде.
2) Аналогичная проблема с инсталляторами. Вендор удалил инсталлятор с сайта — и его больше негде достать.
3) Это так, чистая правда. Не хватает нового поколения пакетных менеджеров — смеси WinSxS хранилища и управления зависимостями APT, c «мягкими» версиями.
4) Опять же, для случая с APT вы его отключите в одном месте ровно один раз. А когда у вас Java Update + Chrome Updater Service + whatever…
В общем, пока две основные болячки пакетных менеджеров — бандлы, которые придут в виде снап-пакетов, и множество версий библиотеки на одной платформе. Но это как-то лучше, чем вообще без пакетного менеджера.
2) Аналогичная проблема с инсталляторами. Вендор удалил инсталлятор с сайта — и его больше негде достать.
3) Это так, чистая правда. Не хватает нового поколения пакетных менеджеров — смеси WinSxS хранилища и управления зависимостями APT, c «мягкими» версиями.
4) Опять же, для случая с APT вы его отключите в одном месте ровно один раз. А когда у вас Java Update + Chrome Updater Service + whatever…
В общем, пока две основные болячки пакетных менеджеров — бандлы, которые придут в виде снап-пакетов, и множество версий библиотеки на одной платформе. Но это как-то лучше, чем вообще без пакетного менеджера.
NixPkg уже есть.
1). Да, я знаю. Я, когда понял, что в Linux проблема с инсталляторами, несколько дней разбирался, как её обойти. Можно, но очень криво получается.
1a). В моде и под Windows, да. Но под Windows при желании всегда можно найти оффлайн-инсталлятор. Я, по крайней мере, не разу ни сталкивался с его отсутствием.
2). Его можно взять со своего жёсткого диска, в первую очередь. Ну и вероятность того, что где-то на сайте-зеркале сохранился один инсталлятор, выше, чем вероятность сохранения всех зависимостей.
Я знаю, что можно вместо папки инсталляторов сохранять папку со скачанными зависимостями, и планировал это делать при уходе на Linux — но это, всё же, не очень удобно.
4). Централизация — это да, этого не хватает.
1a). В моде и под Windows, да. Но под Windows при желании всегда можно найти оффлайн-инсталлятор. Я, по крайней мере, не разу ни сталкивался с его отсутствием.
2). Его можно взять со своего жёсткого диска, в первую очередь. Ну и вероятность того, что где-то на сайте-зеркале сохранился один инсталлятор, выше, чем вероятность сохранения всех зависимостей.
Я знаю, что можно вместо папки инсталляторов сохранять папку со скачанными зависимостями, и планировал это делать при уходе на Linux — но это, всё же, не очень удобно.
4). Централизация — это да, этого не хватает.
ничто не мешает делать локальные репозитории на те-же дисках или в виде некоторого контейнера и устанавливать из него. и интернет не нужен и установочник под рукой.
оффлайн инсталяция для 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-пакет
Но так делать плохо, без лишней на то необходимости
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-пакет
Но так делать плохо, без лишней на то необходимости
http://manpages.ubuntu.com/manpages/precise/man8/apt-zip.8.html
https://wiki.debian.org/AptZip
https://wiki.debian.org/AptZip
Ну да, а еще можно запаковать кэш 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?
Если это так, то это поведение очень напоминает одну компанию, не скажу какую.
А еще есть не завязанный на 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?
Если это так, то это поведение очень напоминает одну компанию, не скажу какую.
WinSxS, MSI? Не в курсе?
«WinSxS — эта та папка что весит 47 гигабайт на диске С? Я ее удалил» //sarcasm
WinSxS это не депенденси менеджмент ни разу. Это просто свалка одних и тех же библиотек разных версий. Причём даже без мягкого версионирования. В рамках WinSxS нельзя зависить от «любой 2.1 выше 2.1.9». А ещё их гениальнейший способ очистки — просто вычищать пакеты, к которым не обращались месяц или около того. Гениально, что сказать.
А в линуксе-то рай! Захотел в Debian 8 пакет из Debian 9 или даже sid. А вот перехочешь, потому что эта либа старая совсем, вот той в 8 вообще нет, а чтобы обновить эту надо чуть ли не ядро менять.и половину системы обновлять. Ну или делаем из Дебиана Слаку с помощью «make install»/«checkinstall». Или городим огород в docker/chroot/nspawn
Захотел самую свежую версию приложения в винде? Скачал, поставил, пользуешься. Загрузчик сам подбросит нужные либы.
Примеры? C помощью dpkg-buildpackage собрать wget и все его зависимости по части tls.
И как аккуратно обошли MSI, типа я и не говорил про него.
Захотел самую свежую версию приложения в винде? Скачал, поставил, пользуешься. Загрузчик сам подбросит нужные либы.
Примеры? C помощью dpkg-buildpackage собрать wget и все его зависимости по части tls.
И как аккуратно обошли MSI, типа я и не говорил про него.
Начну с конца. Про MSI не писал специально, т.к. опыта не сильно много. Но по тому, что есть — это формат-динозавр, на редкость монструозный и кошмарненький. Но это не экспертное, а сугубо личное мнение. Да и как он помогает в этом случае — не совсем понятно.
По поводу всего остального — да, невозможность держать несколько версий одной зависимости это проблема. Большая проблема. Её пытался решить NixPM. Однако, при работе с репозиториями бОльшая часть пакетов согласована. Косяки есть везде. И, как по мне, с пакетным менеджером лучше, чем без него.
По поводу всего остального — да, невозможность держать несколько версий одной зависимости это проблема. Большая проблема. Её пытался решить NixPM. Однако, при работе с репозиториями бОльшая часть пакетов согласована. Косяки есть везде. И, как по мне, с пакетным менеджером лучше, чем без него.
Видимо человек не знает об Uninstall Tool
Если Вы про меня, я как раз знаю. Я только не понимаю, почему для того, чтобы корректно удалить программу в Windows, надо скачать другую стороннюю программу. Похоже, кто-то знает Windows лучше, чем инженеры MS.
Установка/удаление программ стандартная мб?
Вы когда-нибудь ставили Visual Studio 2012 или 2013? Эта зараза пихает в систему ещё 30-40 компонентов. Ну и классика жанра, когда программа гадит в реестре, а при удалении за собой не подчищает.
эта шткуа просто запускает бинарь, который инсталлер указал в реестре в качестве способа удаления того что он туда наустанавливал. Сама система ничего не отслеживает и ничего не удаляет, в отличие от пакетных менеджеров в линуксах. Качество работы анинсталлера остаётся на совести его авторов.
Ну вот из недавнего похожего в линуксе — поставил пакет, который с собой притянул еще три десятка зависимостей, включая midi эмулятор и демон работающий с ALSA. По удалении оказалось что удалились не все пакеты, так как система посчитала что демон теперь будет на постоянной основе жить в системе.
Тут вы правы, все на совести автора, по этому я и юзаю sandboxie (:
Тут вы правы, все на совести автора, по этому я и юзаю sandboxie (:
И каким образом пакетный менеджер что-то отслеживает? Он удалять умеет только то, что сам скопировал, т.е. ничего он не умеет. А весь тот хлам, который поставили установочные скрипты и само приложение, он никак не трогает, потому что про них не знает и знать не может. Все на откуп добросовесным разработчиками, т.е. ровно тоже самое, что и с инсталляторами. Для решения этой проблемы и придумали всяческие песочницы. В винде это сейчас в виде Windows Store, где помимо UWP и для обычных win32 приложений поддержка уже есть. Постепенно, но порядок наводить начинают.
Хуже всего конечно в макоси с pkg установщиками, которые ставят непонятно что непонятно куда и удалять это никто не умеет. Можно только надеяться, что приложение где-то содержит кнопку «uninstall».
Хуже всего конечно в макоси с pkg установщиками, которые ставят непонятно что непонятно куда и удалять это никто не умеет. Можно только надеяться, что приложение где-то содержит кнопку «uninstall».
> Хуже всего конечно в макоси с pkg установщиками
В большинстве случаев оттуда довольно не сложно извлечь сам *.app и руками положить его куда нужно. Иногда там бывают какие-то post/pre install скрипты, которые можно посмотреть глазами и запустить если нужно. В редких случаях попадаются ядерные модули или модули настроек.
Хотя, конечно, из App store ставить проще.
В большинстве случаев оттуда довольно не сложно извлечь сам *.app и руками положить его куда нужно. Иногда там бывают какие-то post/pre install скрипты, которые можно посмотреть глазами и запустить если нужно. В редких случаях попадаются ядерные модули или модули настроек.
Хотя, конечно, из App store ставить проще.
Просто кто-то таки должен взять ситуацию в руки и сделать конвертер из pkg в формулы homebrew в один клик.
Что-то мне сомнительно, что в homebrew примут коммерческий / закрытый софт без исходников (плюс еще могут быть заморочки с EULA, там где запрещена декомпиляция / расковыривание софта)…
Хотя можно, конечно, свой локальный реп держать.
Хотя можно, конечно, свой локальный реп держать.
Не, суть как раз не в том, чтобы ставить их из репозитория — я думаю скорее о деинсталляции пиратского самодельного софта. А так — дропнул pkg на "конвертилку", а оно конвертит в формулу и ставит в /usr/local/, вне зависимости от лицензии и происхождения этого pkg. А потом удаляет оттуда же.
> и ставит в /usr/local/
Тут может быть облом. Мне попадался софт, который хочет быть строго в /Applications, изо всех остальных мест (даже из ~/Applications) он просто не запускается. Симлинки тоже могут не прокатить. Из недавнего — BusyCal. Немного порылся в бинарниках/ресурсах — там этот путь хардкодом в куче мест.
Тут может быть облом. Мне попадался софт, который хочет быть строго в /Applications, изо всех остальных мест (даже из ~/Applications) он просто не запускается. Симлинки тоже могут не прокатить. Из недавнего — BusyCal. Немного порылся в бинарниках/ресурсах — там этот путь хардкодом в куче мест.
Во-первых, не всегда это просто *.app. Для таких простых случаев есть обычные dmg образы. Любят еще ставить апдейтеры всякие, плагины для настроек, демоны и прочие вполне обычные штуки. Во-вторых, приложения в макоси любят складывать хлам по всей файловой системе, что потом это вычищать только с помощью специальных утилит приходится. Даже эпл программы этим страдают. Тот же Xcode вроде бы ставится из AppStore, но свой мусор ткает везде и всюду. Тут и AppStore уже не помогает. Им стоит все таки больше брать пример с iOS, где порядка в файловой системе и с приложениями намного больше. Или с Windows Store, который может навести порядок даже для обычного win32 софта путем виртуализации файловой системы и регистра, чтобы потом одним кликом удалить все и вся без всяких скриптов и вмешательства разработчика.
Проблема тут только в том, что рук уже не хватает, чтобы следить за огромной базой пакетов и программ, которые к тому же еще и растут как грибы после дождя. При этом авторы программ и библиотек не могут себе позволить просто универсальный пакет сделать, который можно было бы просто скачать и использовать. То есть штуки типа snap реально нужны, но в реальности нужна лишь одна такая вещь, которая бы была доступна в любом дистрибутиве. Но они не замена системным пакетным менеджерам.
скажу на примере проекта openmcu-ru. Проект использует специальные патченные версии библиотек ptlib и h323plus, которые конфликтуют с оригинальными системными, поэтому эти библиотеки идут вместе с основным проектом. (не всегда можно договориться о включении новых фич в основной репозиторий библиотек) Так же проект зависит от ffmpeg определенной версии, который в некоторых дистрибутивах avlib.
Поэтому в данный момент чтобы все работало основное приложение нужно ставить специальным скриптом.
Поэтому в данный момент чтобы все работало основное приложение нужно ставить специальным скриптом.
Судя по доке, создавалка snap пакета по формату очень похожа на конфигурационные файлы travis'а или appveyor'а. Подозреваю, если идея взлетит, то всяким юзерским программам станет проще деплоится. Только вот в flatpack есть такая штука, как платформы, которые шарятся между приложениями, тут я пока вижу просто build-parts, в которую нужно вписать инструкции сборки всех зависимостей, что не очень то удобно.
Возможно, когда-нибудь, это может и пригодиться.
снэпы минимизируют негативные последствия возможных уязвимостей
Каким образом?
Если раньше надо было обновить одну уязвимую библиотеку, то со снэпами надо будет обновлять каждый снэп, который от неё зависит. Так?
Это чего, теперь у каждого скрипта на питоне в инсталляхе будет полдистрибутива, начиная с libc?
Разве .deb-пакеты не предоставляют такую возможность на данный момент?
Например можно поставить пакет busybox или busybox-static.
У busybox-static преимущество в том что консоль не сломается если внезапно отвалится корневой каталог / на котором хранятся все либы.
В целом мне кажется это «пятнадцать конкурирующих стандартов».
Теперь разработчикам snap-пакетов придется постоянно следить не обнаружился ли в их пакете очередной SSL Heartbleed.
Например можно поставить пакет busybox или busybox-static.
У busybox-static преимущество в том что консоль не сломается если внезапно отвалится корневой каталог / на котором хранятся все либы.
В целом мне кажется это «пятнадцать конкурирующих стандартов».
Теперь разработчикам snap-пакетов придется постоянно следить не обнаружился ли в их пакете очередной SSL Heartbleed.
Deb тащит просто упоминание о зависимых пакетах. Но ни ссылок, ни самих пакетов он не несет
Deb тащит все файлы которые разработчик пожелает засунуть в свой пакет.
Там могут быть и исполняемые файлы и либы и медиа-ресурсы и скрипты автозагрузки.
Разве что, два разных deb-пакета не могут тащить в себе одинаковые файлы (/lib/XXX), каждый должен тащить свой собственный файл (/usr/lib/YYY/XXX)
Там могут быть и исполняемые файлы и либы и медиа-ресурсы и скрипты автозагрузки.
Разве что, два разных deb-пакета не могут тащить в себе одинаковые файлы (/lib/XXX), каждый должен тащить свой собственный файл (/usr/lib/YYY/XXX)
В deb можно засунуть что угодно, но обычно суют ресурсы и бинарники, а остальное — да, прописывают как зависимости, а дальше пакетный менеджер их разруливает. Что есть правильно, следуя этой идеологии, и лучше их не трогать.
Вот тут один из мэйнтейнеров ArchLinux выступает с критикой snap-пакетов:
kmkeen.com/maintainers-matter/2016-06-15-11-51-16-472.html
Перевод основных положений на опеннете:
www.opennet.ru/opennews/art.shtml?num=44611
Просто для расширения кругозора, и возможности посмотреть на ситуацию с позиции авторитетного специалиста :)
kmkeen.com/maintainers-matter/2016-06-15-11-51-16-472.html
Перевод основных положений на опеннете:
www.opennet.ru/opennews/art.shtml?num=44611
Просто для расширения кругозора, и возможности посмотреть на ситуацию с позиции авторитетного специалиста :)
Сколько же ненависти в Linux сообществе. Каждый первый бородатый и готов мать продать за идейность и непоколебимость.
Места им жалко. А времени и нервов вам не жалко когда приложение А и Б требуют разные версии одной библиотеки в системе? Или сооружение подпорок и мостов из костылей уже в крови? Под каждый чих самолично собирать докер контейнеры. Ммммм… удовольствие.
А в изолированных от интернета окружениях вы пробовали ставить пакеты не из главного репозитория? Вкусно?
Места им жалко. А времени и нервов вам не жалко когда приложение А и Б требуют разные версии одной библиотеки в системе? Или сооружение подпорок и мостов из костылей уже в крови? Под каждый чих самолично собирать докер контейнеры. Ммммм… удовольствие.
А в изолированных от интернета окружениях вы пробовали ставить пакеты не из главного репозитория? Вкусно?
Согласен:
1. Установка старого приложения в новой системе / нового в старой системе;
2. Установка пакетов без интернета
обуславливают использование снэпов.
Во всех остальных случаях вижу лишь минусы перед пакетными менеджерами, начиная от безопасности (не могу согласиться с тезисом из статьи) и отступлениями от гайдлайнов системы, кончая увеличением использования ресурсов.
Кто часто использует два указанных кейса, пожалуйста переходите на снэпы. Но когда этот подход продвигают крупные компании и предполагают его универсальность в будущем, при наличии удобных и надёжных работающих инструментов, это заставляет насторожиться.
1. Установка старого приложения в новой системе / нового в старой системе;
2. Установка пакетов без интернета
обуславливают использование снэпов.
Во всех остальных случаях вижу лишь минусы перед пакетными менеджерами, начиная от безопасности (не могу согласиться с тезисом из статьи) и отступлениями от гайдлайнов системы, кончая увеличением использования ресурсов.
Кто часто использует два указанных кейса, пожалуйста переходите на снэпы. Но когда этот подход продвигают крупные компании и предполагают его универсальность в будущем, при наличии удобных и надёжных работающих инструментов, это заставляет насторожиться.
А времени и нервов вам не жалко когда приложение А и Б требуют разные версии одной библиотеки в системе?
Вот ни разу не было такой проблемы. Зависит от дистра. Обычно этим страдают deb дистры.
Под каждый чих самолично собирать докер контейнеры. Ммммм… удовольствие.
Это я вообще отказываюсь комментировать.
А в изолированных от интернета окружениях вы пробовали ставить пакеты не из главного репозитория? Вкусно?
Да нормально, более того — обычно так и делаю. Один раз выкачиваю пакет и все нужные ему пакеты и ставлю их все скопом. Где проблема тут — не понимаю. Если уж совсем припрёт, то можно заставить пакетный менеджер поставить пакеты, не смотря ни на какие зависимости. Правда результат здесь уже никто и не гарантирует.
>>Да нормально, более того — обычно так и делаю. Один раз выкачиваю пакет и все нужные ему пакеты и ставлю их все скопом.
Как это может быть удобнее выкачивания одного файла? Кроме того: Если не предполагается апдейтить — в чем вообще выигрыш?
Как это может быть удобнее выкачивания одного файла? Кроме того: Если не предполагается апдейтить — в чем вообще выигрыш?
Это если у вас весь софт из дистра.
Когда делаешь пару шагов в сторону (одна прога проприетарная, вторая самописная, третью скачали с заброшенной репы на гитхабе), и их нужно поженить в рамках одной оси — вот тут-то и настаёт День Бубна.
Когда делаешь пару шагов в сторону (одна прога проприетарная, вторая самописная, третью скачали с заброшенной репы на гитхабе), и их нужно поженить в рамках одной оси — вот тут-то и настаёт День Бубна.
Что мешает для мамонтов подготовить пещеру в которой будет весь этот зоопар жить?
Для заброшенных реп вам в любом случае придется настраивать окружение для сборки и собирать все обособленно от системы.
Для самописно — что мешает тупо держать в актуальном состоянии ??? Бибилиотеки редко меняются беспричинно с поломкой всех совместимостей, обычно это означает мажерное обновление, зачастую всей системы. Никтож не жалуется что у людей не получается запустить на 10 mac OS файлы от 8й…
Вобоще почитав комментарии складывает чувство что большинство просто старательно и прицельно стреляют себе по ногам из ружей…
т.е. стараются создать сами себе проблемы.
Да понятно бывают случаи когда надо дружить слабо совместимые вещи, но для этого и придумали изоляцию окружения уже черти знает сколько времени…
все жалуются на то что к репам доступа не будет, хотя никто им не мешает использовать образы репозиториев для локального хранения…
Было-бы желание — найдется инструмент, а так — лень с помесью безумия.
Подобые изолированные пакеты полезны будут в следующих случаях
— редкий огорожденный софт, который никто не собирается поддерживать.
— билды софта для демонстраций (альфы, беты, превью)
больше я незнаю нафига это нужно, весь остальной софт имхо должен нормально работать с репозиториями, это стандартный механизм, боле менее гарантирующий совместимость внутри текущего релиза + позволяющий адекватно использовать функционал библиотек стандартной поставки и не засорять мусором систему.
Для заброшенных реп вам в любом случае придется настраивать окружение для сборки и собирать все обособленно от системы.
Для самописно — что мешает тупо держать в актуальном состоянии ??? Бибилиотеки редко меняются беспричинно с поломкой всех совместимостей, обычно это означает мажерное обновление, зачастую всей системы. Никтож не жалуется что у людей не получается запустить на 10 mac OS файлы от 8й…
Вобоще почитав комментарии складывает чувство что большинство просто старательно и прицельно стреляют себе по ногам из ружей…
т.е. стараются создать сами себе проблемы.
Да понятно бывают случаи когда надо дружить слабо совместимые вещи, но для этого и придумали изоляцию окружения уже черти знает сколько времени…
все жалуются на то что к репам доступа не будет, хотя никто им не мешает использовать образы репозиториев для локального хранения…
Было-бы желание — найдется инструмент, а так — лень с помесью безумия.
Подобые изолированные пакеты полезны будут в следующих случаях
— редкий огорожденный софт, который никто не собирается поддерживать.
— билды софта для демонстраций (альфы, беты, превью)
больше я незнаю нафига это нужно, весь остальной софт имхо должен нормально работать с репозиториями, это стандартный механизм, боле менее гарантирующий совместимость внутри текущего релиза + позволяющий адекватно использовать функционал библиотек стандартной поставки и не засорять мусором систему.
Такой софт всё ещё собирается в пакеты, никаких отличий от системных там нет. Да и редко такие встречаются, если честно. На кой фиг мне нужен древний софт?
На кой фиг нужно реинсталлить\обновлять всю систему ради одной программы, которая тянет либу из testing?
Ну так и качайте только одну либу из testing, кто запрещает то? Чего вы сами себе проблемы выдумываете?
Проблема в том, что та либа тянет за собой еще кучу всякого дерьма из testing.
В Snap пакете всё-равно потребуется эта либа и её зависимости, т.е. выкачивать примерно один объём данных. Где профит то, или какая-то проблема?
Почему это примерно один?
Установка GIMP'a потянет за собой выкачивание пол-Гнома.
Установка Cheese тоже потянет за собой выкачивание пол-Гнома.
Однако если я установлю Cheese после GIMP'a (а равно как после многих других, более обязательных программ), мне потребуется выкачать всего 5 мегабайт.
И я пытаюсь понять, придется ли ради каждой программы выкачивать ВСЕ ее зависимости?
Установка GIMP'a потянет за собой выкачивание пол-Гнома.
Установка Cheese тоже потянет за собой выкачивание пол-Гнома.
Однако если я установлю Cheese после GIMP'a (а равно как после многих других, более обязательных программ), мне потребуется выкачать всего 5 мегабайт.
И я пытаюсь понять, придется ли ради каждой программы выкачивать ВСЕ ее зависимости?
Прочитал заголовок статьи. Думал очередное изобретение Потеринга. Ан-нет, ошибся.
Не совсем понимаю целесообразность этих телодвижений. И во что это выльется в системе в итоге. Если после установки пакета у меня будет каталог что-то типа /usr/software/uber_soft/ с бинарником и либами внутри папки — то я согласен, это будет круто. Думаю можно будет написать скрипт, который прошарится по диску, найдет одинаковые либы, и сделает вместо их всех, симлинки на один экземпляр.
Но если это будет в стиле «скинем все в /usr/lib, дадим номер версии, в зависимостях не пропишем, а там пусть юзер сам учится удалять, и вообще это опенсорс, не нравится — не пользуйтесь и прочее бла бла бла» — то пожалуй это возненавидят еще больше чем systemd.
Как по мне, в никсовом мире, есть масса более актуальных проблем. Например допилить наконец вменяемый графический сервер (привет, Mir), перепилить IO-стек (сижу на NVMe 2.5Gb read, 1.4 Gb write, а быстрее не стало, в отличие от Винды), разобраться с поддержкой оборудования. Нет, страдают херней.
Не совсем понимаю целесообразность этих телодвижений. И во что это выльется в системе в итоге. Если после установки пакета у меня будет каталог что-то типа /usr/software/uber_soft/ с бинарником и либами внутри папки — то я согласен, это будет круто. Думаю можно будет написать скрипт, который прошарится по диску, найдет одинаковые либы, и сделает вместо их всех, симлинки на один экземпляр.
Но если это будет в стиле «скинем все в /usr/lib, дадим номер версии, в зависимостях не пропишем, а там пусть юзер сам учится удалять, и вообще это опенсорс, не нравится — не пользуйтесь и прочее бла бла бла» — то пожалуй это возненавидят еще больше чем systemd.
Как по мне, в никсовом мире, есть масса более актуальных проблем. Например допилить наконец вменяемый графический сервер (привет, Mir), перепилить IO-стек (сижу на NVMe 2.5Gb read, 1.4 Gb write, а быстрее не стало, в отличие от Винды), разобраться с поддержкой оборудования. Нет, страдают херней.
npm так и работает. Удобно, не боишься что установка очередной библотеки приведет к конфликту версий или еще чему-то. А главное что каждая версия библитеки протестирована на конкретных версиях зависимостей.
знаете, npm это просто маленький филиал ада, давайте не будет его тут расковыривать а том думгая придется звать…
Если так подумать все пакетные менеджеры — это ад. У одних одни проблемы у других проблемы другого рода. Так что давайте не преувеличивать. Ну или напишите свой идеальный пакетный менеджер
Как действительно работает NPM можно узнать примерно здесь — https://habrahabr.ru/post/280039/
И да и нет, понятно что у любого механизма есть та или иная проблема. Но лично у меня мозоль с языка не сходит от мата что я несу когда приходится работать с данным пакетным менеджером. Тяжелый, медленный, проблемы зависимостей, удаление старых версий модулей которые ты использовал гдет.
Все чаще посещаю мысли избавится от него нафиг.
Все чаще посещаю мысли избавится от него нафиг.
Кто-то наконец включил мозги и решил наконец выйти из этого тупика, сделать так чтобы софт работал в любом дистре, независимо от степени кривизны разрабов и дистров и софта. Теперь осталось сделать нормальный гуй и устранить исторические анахренизмы.
PS: Про GoboLinux конечно никто не слышал. Там это решено на уровне fs — просто и элегантно. Практически как на маке.
PS: Про GoboLinux конечно никто не слышал. Там это решено на уровне fs — просто и элегантно. Практически как на маке.
Распространяются они только напрямую, без использования репозиториев?
И как в том же Arch например с ними работать?
И как в том же Arch например с ними работать?
Я сейчас задам глупый, нубский вопрос, но тем не менее прошу дать на него умный ответ. Тут очень многие пишут о 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?
Если так, то, может, решать проблему нужно с другого конца?
Нынешний подход линковщика учитывает 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, т.е. приложение в любом случае не запустится.
Т.е. есть приложение 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, т.е. приложение в любом случае не запустится.
Но приложение то слинковано с 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-пакетов?
MAC style
Нет, с чего вы взяли?
В OS X есть две разных семантики библиотек. Одна — .dylib, полностью аналогична .so в Linux, и страдает от тех же проблем.
Вторая — бандлы фреймворков [1][2], в которых используется семантическое версионирование, параллельная установка, динамическая выгрузка (в отличие от dlclose, который на самом деле не обязан ничего выгружать — и не выгружает), и всякое такое.
На маках есть свои проблемы, но dependency hell среди них нет.
нет, я про методологию установки.
>> dependency hell среди них нет.
Но есть проблема с мусором который остается от пакетов и невозможностью нормального удаления пакетов, в виду отсутсвия механизма удаления библиотек.
у них не dependency hell а dependency limb )))
>> dependency hell среди них нет.
Но есть проблема с мусором который остается от пакетов и невозможностью нормального удаления пакетов, в виду отсутсвия механизма удаления библиотек.
у них не dependency hell а dependency limb )))
Остается, да. Но это не отсутствие механизма удаления библиотек, а отсутствие встроенного пакетного менеджера. Можно, конечно, через pkgutil --files com.teamviewer.teamviewer10 смотреть, что и куда установлено, и удалять руками… А можно пользоваться homebrew, macports и иже с ними, которые более-менее решают эту проблему для софта из репозиториев. Возможно, есть решения и для чистого удаления сторонних .pkg-шек, но я не искал.
Что-то сдается мне, что написать простейшую обертку над pkgutil --pkgs / pkgutil --files — это дело элементарное. Странно, что в дефолтной макоси этого нет.
Проблема в скриптах пре- и пост-установки, которые могут быть в pkg (ради которых pkg и делают, собственно), причем скрипты не обязательно написаны на shell — это могут быть вообще произвольные бинарники, внутрь которых заглянешь только дизассемблером. Поэтому в общем случае макось не знает, что они творят, и в --files не вносит. Как вариант, решается это виртуализацией процесса установки, чтобы перехватить все операции над ФС и defaults, но в Apple по какой-то причине не стали заморачиваться. Может быть, кто-то заморочится?
С виртуализацией тут вот такая проблема есть — некоторый софт ставит ядерные модули, например. А другому нужен доступ ко всяким низкоуровневым API. Я уже тоже подумывал про встроенный механизм песочницы/контейнеров, но поковырявшись пару вечеров с заведением скайпа там — плюнул на это дело.
Ну, чисто теоретически, опять же, можно поверх mach нахреначить гипервизор… Позаворачивать все сисколлы на гипервизор, а оттуда в юзерспейс перекидывать лог действий. Но у меня что-то руки немного опускаются от перспектив подобных извращений — причем я даже не уверен, не работает ли ядро УЖЕ на -1 кольце, или не занимают ли его проги типа Parallels. Вроде ведь как делать цепочки гипервизоров пока нельзя?
Да. я как-бы о том-же.
Решения нет — я искал, ужасался.
честно говоря подобное немного ставит в ступор, непонятна позиция apple.
Из действенных — ставить из псевдорепозиториев — homebrew, macports.
Решения нет — я искал, ужасался.
честно говоря подобное немного ставит в ступор, непонятна позиция apple.
Из действенных — ставить из псевдорепозиториев — homebrew, macports.
Да не псевдо они, вполне настоящие — как минимум, homebrew. С макпортами плотно не работал, за них сказать не могу. Или почему вы их "псевдо" считаете?
А по поводу решения — может, раз уж Эппл пошла копать в направлении сэндбокса системы, то в 10.12 будет песочница для произвольных приложений? Сейчас песочницы для приложений из стора уже есть, но толку от них.
не коробочное решение, потому и «псевдо», не более.
А толку, песочница песочнийцей, но больше всегда интересовала работа с пакетами, а там все плохо.
Да и всеравно это не решит проблему взаимосвязи приложений, только еще больше может раздуть дистрибьютивы приложений (вообще в маке на мой взгляд самый большие дистрибьютивы, т.е. блокнот весящий 100мб это вполне норимально для мака)
Да и всеравно это не решит проблему взаимосвязи приложений, только еще больше может раздуть дистрибьютивы приложений (вообще в маке на мой взгляд самый большие дистрибьютивы, т.е. блокнот весящий 100мб это вполне норимально для мака)
А, ну и стоит отдельно отметить, что пакетные менеджеры в Линуксе, например, не ведут учет файлов, которые были созданы после того, как пакет был установлен. Поэтому если пакет не говорит, как именно его деинсталлировать, этот мусор останется висеть.
С программами в Windows та же ситуация — если деинсталлятор предпочтет что-то оставить в системе (какую-то расшаренную библиотеку, или лицензионную информацию) — он их оставит.
Маки в этом плане не исключение.
с Linux на самом деле все понятно, да мусорят все, в той или иной мере, но чаще всего мусор образуется в home/ папке, в корне все старые пакеты стараются описывать файлы и папки которыми они оперируют и проблем в будущем не создают.
Впрочем всегда найдутся исключения.
Впрочем всегда найдутся исключения.
Вот не кажется мне это хорошей идеей. Притащили инсталляторы из Windows, хотя для меня одним из серьезных преимуществ Linux является как раз установка из репозиториев. Это в разы удобнее поисков и выкачиваний инсталляторов, а еще не приходится задумываться, что вот этот инсталлятор притащит с собой еще какой-нибудь Mega System Boost Registry Cleaner 10.1 и еще пару адварь. А так многие могут теперь забить на добавление софта в репозитории и привет mail.ru агенты еще и на Linux. И зачем?
А то deb не может с собой ничего притащить. Запросто это сделает и никто ничего не заметит, если не ковырять весь deb пакет. А т.к. из под рута запускаем, то успешно установит все, что ему вздумается. Нет никакой принципиальной разницы в том, чтобы качать инсталлятор с сайта или с репозитория. Репозиторий это тот же сайт, который просто напросто понятен консольной утилите. Точно так же нужно искать репозитории, если нужно что-то поставить. Особенно свежую версию софта. Как то nginx или docker, которые в ubuntu trusty у меня качались старых версий. И тем более, если софт вообще не входит в стандартный набор.
Репозиторий это тот же сайт, который просто напросто понятен консольной утилите
В обычном случае нет
Точно так же нужно искать репозитории, если нужно что-то поставить
Не нужно. У меня включены только официальные + несколько ну очень популярных. Если в них чего-то нет, я сама сделаю пакетик, используя спек из src.rpm «палевного» репозитория(проверив его!), и тарболл с сайта автора программы.
Вот поясните мне, пожалуйста — для Raspberry Pi под Ubuntu мне доступен пакет и через apt и через snap. На уязвимости мне абсолютно пофиг, тестовая железка в локальной подсети, а вот объем отжираемой памяти очень критичен. Как лучше ставить пакет — какие явные ± у каждого решения?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Snap-пакеты теперь будут доступны во многих дистрибутивах Linux (а в будущем, возможно, и в Windows)