Comments 167
Они вроде имеют поддержку AppArmor. А полная изоляция (как в docker и lxc) не сильно нужна десктопным приложениям, ибо ломает их интеграцию. Попробуйте, например, запустить Qt-приложение в docker-контейнере с системным стилем виджетов.
ИМХО: Это жуткий шаг не туда. Многие сторонники линукса ставят во главу угла то что библиотеки для зависимостей не надо качать для каждой программы, а тут предлагают типичный для некоторых виндоузовских программ сценарий — возьмем все и сольем в один exe-шник.
Разрулить можно, но это тот ещё квест.
Ну, это пока…
Я не знаю, как это делается, но если в системе так сложно запустить бинарник с теми либами, которые я хочу, а не теми, которые хочет система, то что-то в системе не так.
1) Разве нельзя выкачать произвольную версию бинарника либы из системного репозитория?
2) Если кто-то распространяет бинарники без описания зависимостей, то это вроде не системы проблема.
1) Можно.
2) Зависимости есть, но прога А требует foo.lib версии 1.01, а прога Б требует foo.lib версии 1.05, то есть какую-то придётся выкачивать и класть отдельно, запуская бинарник именно с ней. А чтобы потом всё так и работало — скрипт запуска сочинять.
Может как-то и проще можно, я не эксперт в линуксах, просто пользователь.
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 будет установлен
Вроде в генту, с её любовью к сборке из исходников, можно и несколько версий одной библиотеки держать, но это сложно, а запаковать в один блоб — просто.
Если дисковое место можно особо не экономить — его в последнее время более чем достаточно, то оперативной памяти никогда много не бывает.
Пока приложений в линуксах аналогичных нет и их не пишут — говорить не о чём.
…
Пророчества о наступлении вендекапца появлялись после выхода ReactOS 1.0, Bolgenos 1.2, Wine 1.0, Слаки 13.0 и ядра линукса 4.0.» © Лурк
Беспроблемная работа драйверов на 2.6.32, никогда не падающие Иксы и многое другое в очередном маркетинговом буллшите от Каноникал!
Когда кто-то анонсирует новую убертехнологию и агитирует за её использование — ничто не мешает мне агитировать против её использования.
I.e когда 2 snap-приложения зависят от взаимоисключающих параметрах ядра — одно не заработает; когда snap-приложение не сможет в установленный X сервер — оно его уронит или не запустится.
Когда Red Hat в каждой второй публикации половину займет рассуждениями о проблемах бездомных кенгуру в Нигерии, я буду писать о том, что кто-то сошёл с ума.
Использование формата snap позволит разработчикам Ubuntu значительно быстрее создавать пакеты с новыми версиями рабочих окружений или прикладных программ. Особенность формата ещё и в том, что устанавливаемое с их помощью ПО изолировано от системы и не оказывает на неё никакого влияния. Подобная схема значительно более надёжна и безопасна.
Пакеты snap обладают определёнными преимуществами для программистов, создающих прикладное ПО для настольных машин, серверов, мобильных устройств или IoT. Единый инструмент избавит их от необходимости применять виртуальную среду для написания и тестирования приложений.
Разработчикам платных программ больше не потребуется отслеживать все зависимости и совместимости с различными системными библиотеками, что особенно актуально для старых версий Ubuntu. По этой причине Canonical планирует убедить программистов перевести все подобные решения из deb в snap уже осенью текущего года, тем более что их интерес тут также очевиден.
Вместе с этим, не может быть и речи про отказ от deb. Соответствующие пакеты будут поддерживаться, в том числе и в Ubuntu 16.04, чтобы быть доступными для всех желающих.
источник
Пока ярые фанатики считали килобайты установочных составляющих, Windows положила на это болт и выпускала приложения от десяток до сотен мегабайт. Когда интернет был 64 Кб/с а жесткий диск — 504 МБ это было бы проблемой, но сейчас скорость у многих под 100 Мб/с (не у всех, конечно, но скорость интернета увеличилась на порядки) и даже на бюджетниках уже можно найти под 1ТБ жесткий диск. Соответственно, один из главных недостатков нивелируется — сейчас многим наплевать, сколько весит инсталлятор. Если он даёт определенные преимущества разработчикам и пользователями — пусть будет, пусть вообще везде будет, где может быть. Ну а относительно того, что им могут заменить deb — в OpenSource всегда можно всё поправить, разработчики не обладают монополией и каждый может поменять дистрибутив на свой вкус, этим и славятся дистрибутивы Linux.
Ваш же комментарий не несёт никакой здравой критики или информации, вы просто сказали, что Debian рутой, а маркетинг Каноникал вам не по душе. Причём тут всё это?
Если так, то новость замечательная, отсутствие нормальных инсталляторов — пожалуй, главное, что меня уже который год удерживает от ухода с Windows на Linux.
*собрался читать про Snap подробнее*
PS: Я под защитой убунты!
Нет, я ничего не имею против консоли. Я только хочу и дальше иметь папочку, в которой лежат stand-alone инсталляторы, которыми можно пользоваться самому и давать знакомым вне зависимости от состояния репозиториев.
А будут эти инсталляторы запускаться из-под консоли, или из GUI — мне, в общем, плевать.
Но я где-то год назад пытался найти способ использовать инсталляторы (и, вроде, изучил все существующие варианты) — пришёл к тому, что все существующие решения слишком кривы, чтобы использовать их для установки всего ПО в системе.
Хочется верить, что появление нативной поддержки snap-пакетов решило эту проблему.
Т. е. одну копию qt на всех тащить бесит, а по qt на каждое приложение — не бесит, ок.
Как часто ваши stand-alone-инсталляторы обновляются? Сколько у вас в той папочке уже скопилось уязвимостей, в том числе RCE — никому неведомо. Благодаря этим уязвимостям часть инсталляторов в той папочке уже, возможно, чем-то заражена. И это не считая того, также замечательного, факта, что вы устанавливаете на свой компьютер ПО, взятое вашим приятелем не пойми откуда, возможно, с троянами и прочей нечистью, вместо того, чтобы взять проверенную версию из ненадёжного источника.
Делайте, что хотите, на Windows, но не тащите этот мусор в GNU/Linux, позязя!
P. S. И не рассказывайте, пожалуйста, про антивирусы. Антивирусы — это последнее прибежище безысходности.
Зависимость — только от официальных репозиториев ОС, если они накроются, то всё равно надо бежать с этой ОС подальше. И почему нельзя отказаться от какого-то определённого обновления, мне тоже непонятно.
Это один из принципов Linux — понимай что делаешь, а не твори магию, как в винде. Если творишь магию и тебе это неудобно — ССЗБ.
Чем отличается установка нужной мне программы из стороннего репозитория (я на 12.04 сижу и мне не обновится просто так) и установка заранее подготовленного инсталляционного пакета с сайта производителя? Я не буду говорить о зависимостях, сделаем вид что их нет. Есть просто ppa от производителя и его-же deb выложенный на сайте. Где разница?
Отвечу вам сам-же: Ее нет. Если производителя скомпрометирует хакер Вася, то я точно так-же получу завирусованный пакет. Разницы никакой.
Про магию мне немного смешно: Что вы подразумеваете под ней? Я под windows всегда ставлю то что знаю куда и как поставится. Я качаю установщики для программ с сайтов-производителей, по возможности это портейбл-версии, и как-то ни разу не было проблем с вирусами, мейлру крапом или «магией».
И да: Я всегда понимаю что я творю в своем дистрибе и стараюсь все свести все к минимализму, в том числе наличие сторонних библиотек и демонов.
«запустил консоль → ввел непонятные команды для подключения ppa → ввел apt-get» неудобны конечному пользователю — караются непониманием.
вне контекста snap-пакетов (которые, ИМХО, бесполезны, но вполне в стиле оказуаливания Linux'а от убунты и наверняка кому-то понравятся).
Про магию мне немного смешно: Что вы подразумеваете под ней?
Когда ты вводишь "непонятные команды", меняешь значения регистра, которое ты понятия не имеешь на что влияет и т.д. 95% инструкций для решения проблем на Win вообще не подразумевают осознания собственных действий. Многие сисадмины решают проблемы "рецептом" из набора. Конечно некоторые делают такие инструкции и для Linux, но это как раз перенос Win-way на Lixux.
У меня есть рабочий линукс, так получилось что он у меня есть. Развиваться в сисадмина я не хочу, потому что а) это мне не нужно б) я не заинтересован вовсе в изучении данной темы за свое личное время в) мне за это не платят. По этому я на каждый чих активно гуглю. Некоторые проблемы решаются быстро, как например установка обычных прав на 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.
Люди вот вполне полноценно pacman портировали и запилили поверх него msys2, как-то не помогает. Проблема с пакетным менеджером в винде это капля в море.
А просто когда-то давно пакеты старых версий были установлены через dpkg, и теперь pip не может их обновить. После удаления через системный пакетный менеджер всё сразу поставится как надо…
Всё это шаманство было бы не нужно, если бы сразу все зависимости поставлялись вместе с приложением единым бандлом. Поэтому snap-пакеты могут сильно упростить жизнь, когда начинается какая-нибудь ерунда с зависимостями.
Текущие инсталяторы в винде зло, так как они часто не следуют гайдланам, и к ним стараются кучу всего прицепить (все библиотеки и фреймворки, как мы в этом топе и обсуждаем). Из-за совместимостей и придумано альтернативное API UWP. Есть конечно с этим и проблемы, но я не думаю что в обозримом будущем винда откажется от win32 приложений.
А теперь внимание. В Windows вы тащите инсталлятор. Руками. Ставите его. Инсталлятор ставит свой обновлятор и ещё кучу мусора. Плюс ещё по копии уже установленных системных либ. Когда вам не нужно это приложение — вы сначала сносите его, а потом долго и скрупулёзно вычищаете зависимости. Руками. Это если один из инсталляторов не был криво написан — так, что валится на процедуре деинсталляции.
Теперь линукс. Вы заходите в пакетный менеджер — и ставите нужный пакет. Вам не нужно думать, что для этого пакета надо доустановить ещё Mono и Python. Когда выходят апдейты — их наличие проверяет один (!) сервис. Который вы настроили один раз. Когда вам не нужен пакет — вы через тот же интерфейс пакетного менеджера помечаете его на удаление. После чего пакетный менеджер сам (!) проверяет, какие пакеты больше никому не нужны, и предлагает их удалить за компанию.
Пишу вам как человек, который почти всю свою сознательную жизнь просидел на Windows, а на Linux перешёл прошлой осенью.
Но:
1). Для установки зависимостей нужен интернет, который не всегда есть под рукой.
2). Для установки зависимостей нужно, чтобы эти зависимости (и сами устанавливаемые программы) всё ещё были в репозиториях, а не оказались удалены за ненадобностью. Не доверяю облакам — может быть, и зря, но я по жизни параноик.
3). Тут уже писали, что из-за использования зависимостей возникают проблемы использования нового ПО под старой системой. Для меня, любителя пользоваться десятилетней ОС и зоопарком программ разного возраста, это неприятно.
4). Что касается автообновления, то я его вообще всегда стараюсь отключать. Обновляться мне удобнее тогда, когда есть время разбираться с новшествами, читать мануалы и всё такое.
Понятно, что проблемы связаны с моим личным характером в целом и стилем использования компьютера в частности, но за всех я и не говорю.
2) Аналогичная проблема с инсталляторами. Вендор удалил инсталлятор с сайта — и его больше негде достать.
3) Это так, чистая правда. Не хватает нового поколения пакетных менеджеров — смеси WinSxS хранилища и управления зависимостями APT, c «мягкими» версиями.
4) Опять же, для случая с APT вы его отключите в одном месте ровно один раз. А когда у вас Java Update + Chrome Updater Service + whatever…
В общем, пока две основные болячки пакетных менеджеров — бандлы, которые придут в виде снап-пакетов, и множество версий библиотеки на одной платформе. Но это как-то лучше, чем вообще без пакетного менеджера.
NixPkg уже есть.
1a). В моде и под Windows, да. Но под Windows при желании всегда можно найти оффлайн-инсталлятор. Я, по крайней мере, не разу ни сталкивался с его отсутствием.
2). Его можно взять со своего жёсткого диска, в первую очередь. Ну и вероятность того, что где-то на сайте-зеркале сохранился один инсталлятор, выше, чем вероятность сохранения всех зависимостей.
Я знаю, что можно вместо папки инсталляторов сохранять папку со скачанными зависимостями, и планировал это делать при уходе на Linux — но это, всё же, не очень удобно.
4). Централизация — это да, этого не хватает.
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-пакет
Но так делать плохо, без лишней на то необходимости
https://wiki.debian.org/AptZip
А еще есть не завязанный на 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?
Если это так, то это поведение очень напоминает одну компанию, не скажу какую.
Захотел самую свежую версию приложения в винде? Скачал, поставил, пользуешься. Загрузчик сам подбросит нужные либы.
Примеры? C помощью dpkg-buildpackage собрать wget и все его зависимости по части tls.
И как аккуратно обошли MSI, типа я и не говорил про него.
По поводу всего остального — да, невозможность держать несколько версий одной зависимости это проблема. Большая проблема. Её пытался решить NixPM. Однако, при работе с репозиториями бОльшая часть пакетов согласована. Косяки есть везде. И, как по мне, с пакетным менеджером лучше, чем без него.
эта шткуа просто запускает бинарь, который инсталлер указал в реестре в качестве способа удаления того что он туда наустанавливал. Сама система ничего не отслеживает и ничего не удаляет, в отличие от пакетных менеджеров в линуксах. Качество работы анинсталлера остаётся на совести его авторов.
Тут вы правы, все на совести автора, по этому я и юзаю sandboxie (:
Хуже всего конечно в макоси с pkg установщиками, которые ставят непонятно что непонятно куда и удалять это никто не умеет. Можно только надеяться, что приложение где-то содержит кнопку «uninstall».
В большинстве случаев оттуда довольно не сложно извлечь сам *.app и руками положить его куда нужно. Иногда там бывают какие-то post/pre install скрипты, которые можно посмотреть глазами и запустить если нужно. В редких случаях попадаются ядерные модули или модули настроек.
Хотя, конечно, из App store ставить проще.
Просто кто-то таки должен взять ситуацию в руки и сделать конвертер из pkg в формулы homebrew в один клик.
Хотя можно, конечно, свой локальный реп держать.
Не, суть как раз не в том, чтобы ставить их из репозитория — я думаю скорее о деинсталляции пиратского самодельного софта. А так — дропнул pkg на "конвертилку", а оно конвертит в формулу и ставит в /usr/local/, вне зависимости от лицензии и происхождения этого pkg. А потом удаляет оттуда же.
Тут может быть облом. Мне попадался софт, который хочет быть строго в /Applications, изо всех остальных мест (даже из ~/Applications) он просто не запускается. Симлинки тоже могут не прокатить. Из недавнего — BusyCal. Немного порылся в бинарниках/ресурсах — там этот путь хардкодом в куче мест.
Проблема тут только в том, что рук уже не хватает, чтобы следить за огромной базой пакетов и программ, которые к тому же еще и растут как грибы после дождя. При этом авторы программ и библиотек не могут себе позволить просто универсальный пакет сделать, который можно было бы просто скачать и использовать. То есть штуки типа snap реально нужны, но в реальности нужна лишь одна такая вещь, которая бы была доступна в любом дистрибутиве. Но они не замена системным пакетным менеджерам.
Поэтому в данный момент чтобы все работало основное приложение нужно ставить специальным скриптом.
Судя по доке, создавалка snap пакета по формату очень похожа на конфигурационные файлы travis'а или appveyor'а. Подозреваю, если идея взлетит, то всяким юзерским программам станет проще деплоится. Только вот в flatpack есть такая штука, как платформы, которые шарятся между приложениями, тут я пока вижу просто build-parts, в которую нужно вписать инструкции сборки всех зависимостей, что не очень то удобно.
снэпы минимизируют негативные последствия возможных уязвимостей
Каким образом?
Если раньше надо было обновить одну уязвимую библиотеку, то со снэпами надо будет обновлять каждый снэп, который от неё зависит. Так?
Например можно поставить пакет busybox или busybox-static.
У busybox-static преимущество в том что консоль не сломается если внезапно отвалится корневой каталог / на котором хранятся все либы.
В целом мне кажется это «пятнадцать конкурирующих стандартов».
Теперь разработчикам snap-пакетов придется постоянно следить не обнаружился ли в их пакете очередной SSL Heartbleed.
Там могут быть и исполняемые файлы и либы и медиа-ресурсы и скрипты автозагрузки.
Разве что, два разных deb-пакета не могут тащить в себе одинаковые файлы (/lib/XXX), каждый должен тащить свой собственный файл (/usr/lib/YYY/XXX)
kmkeen.com/maintainers-matter/2016-06-15-11-51-16-472.html
Перевод основных положений на опеннете:
www.opennet.ru/opennews/art.shtml?num=44611
Просто для расширения кругозора, и возможности посмотреть на ситуацию с позиции авторитетного специалиста :)
Места им жалко. А времени и нервов вам не жалко когда приложение А и Б требуют разные версии одной библиотеки в системе? Или сооружение подпорок и мостов из костылей уже в крови? Под каждый чих самолично собирать докер контейнеры. Ммммм… удовольствие.
А в изолированных от интернета окружениях вы пробовали ставить пакеты не из главного репозитория? Вкусно?
1. Установка старого приложения в новой системе / нового в старой системе;
2. Установка пакетов без интернета
обуславливают использование снэпов.
Во всех остальных случаях вижу лишь минусы перед пакетными менеджерами, начиная от безопасности (не могу согласиться с тезисом из статьи) и отступлениями от гайдлайнов системы, кончая увеличением использования ресурсов.
Кто часто использует два указанных кейса, пожалуйста переходите на снэпы. Но когда этот подход продвигают крупные компании и предполагают его универсальность в будущем, при наличии удобных и надёжных работающих инструментов, это заставляет насторожиться.
А времени и нервов вам не жалко когда приложение А и Б требуют разные версии одной библиотеки в системе?
Вот ни разу не было такой проблемы. Зависит от дистра. Обычно этим страдают deb дистры.
Под каждый чих самолично собирать докер контейнеры. Ммммм… удовольствие.
Это я вообще отказываюсь комментировать.
А в изолированных от интернета окружениях вы пробовали ставить пакеты не из главного репозитория? Вкусно?
Да нормально, более того — обычно так и делаю. Один раз выкачиваю пакет и все нужные ему пакеты и ставлю их все скопом. Где проблема тут — не понимаю. Если уж совсем припрёт, то можно заставить пакетный менеджер поставить пакеты, не смотря ни на какие зависимости. Правда результат здесь уже никто и не гарантирует.
Как это может быть удобнее выкачивания одного файла? Кроме того: Если не предполагается апдейтить — в чем вообще выигрыш?
Когда делаешь пару шагов в сторону (одна прога проприетарная, вторая самописная, третью скачали с заброшенной репы на гитхабе), и их нужно поженить в рамках одной оси — вот тут-то и настаёт День Бубна.
Для заброшенных реп вам в любом случае придется настраивать окружение для сборки и собирать все обособленно от системы.
Для самописно — что мешает тупо держать в актуальном состоянии ??? Бибилиотеки редко меняются беспричинно с поломкой всех совместимостей, обычно это означает мажерное обновление, зачастую всей системы. Никтож не жалуется что у людей не получается запустить на 10 mac OS файлы от 8й…
Вобоще почитав комментарии складывает чувство что большинство просто старательно и прицельно стреляют себе по ногам из ружей…
т.е. стараются создать сами себе проблемы.
Да понятно бывают случаи когда надо дружить слабо совместимые вещи, но для этого и придумали изоляцию окружения уже черти знает сколько времени…
все жалуются на то что к репам доступа не будет, хотя никто им не мешает использовать образы репозиториев для локального хранения…
Было-бы желание — найдется инструмент, а так — лень с помесью безумия.
Подобые изолированные пакеты полезны будут в следующих случаях
— редкий огорожденный софт, который никто не собирается поддерживать.
— билды софта для демонстраций (альфы, беты, превью)
больше я незнаю нафига это нужно, весь остальной софт имхо должен нормально работать с репозиториями, это стандартный механизм, боле менее гарантирующий совместимость внутри текущего релиза + позволяющий адекватно использовать функционал библиотек стандартной поставки и не засорять мусором систему.
Установка GIMP'a потянет за собой выкачивание пол-Гнома.
Установка Cheese тоже потянет за собой выкачивание пол-Гнома.
Однако если я установлю Cheese после GIMP'a (а равно как после многих других, более обязательных программ), мне потребуется выкачать всего 5 мегабайт.
И я пытаюсь понять, придется ли ради каждой программы выкачивать ВСЕ ее зависимости?
Не совсем понимаю целесообразность этих телодвижений. И во что это выльется в системе в итоге. Если после установки пакета у меня будет каталог что-то типа /usr/software/uber_soft/ с бинарником и либами внутри папки — то я согласен, это будет круто. Думаю можно будет написать скрипт, который прошарится по диску, найдет одинаковые либы, и сделает вместо их всех, симлинки на один экземпляр.
Но если это будет в стиле «скинем все в /usr/lib, дадим номер версии, в зависимостях не пропишем, а там пусть юзер сам учится удалять, и вообще это опенсорс, не нравится — не пользуйтесь и прочее бла бла бла» — то пожалуй это возненавидят еще больше чем systemd.
Как по мне, в никсовом мире, есть масса более актуальных проблем. Например допилить наконец вменяемый графический сервер (привет, Mir), перепилить IO-стек (сижу на NVMe 2.5Gb read, 1.4 Gb write, а быстрее не стало, в отличие от Винды), разобраться с поддержкой оборудования. Нет, страдают херней.
Все чаще посещаю мысли избавится от него нафиг.
PS: Про GoboLinux конечно никто не слышал. Там это решено на уровне fs — просто и элегантно. Практически как на маке.
И как в том же 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
?
Если так, то, может, решать проблему нужно с другого конца?
Т.е. есть приложение 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-пакетов?
Нет, с чего вы взяли?
В OS X есть две разных семантики библиотек. Одна — .dylib, полностью аналогична .so в Linux, и страдает от тех же проблем.
Вторая — бандлы фреймворков [1][2], в которых используется семантическое версионирование, параллельная установка, динамическая выгрузка (в отличие от dlclose
, который на самом деле не обязан ничего выгружать — и не выгружает), и всякое такое.
На маках есть свои проблемы, но dependency hell среди них нет.
>> dependency hell среди них нет.
Но есть проблема с мусором который остается от пакетов и невозможностью нормального удаления пакетов, в виду отсутсвия механизма удаления библиотек.
у них не dependency hell а dependency limb )))
Остается, да. Но это не отсутствие механизма удаления библиотек, а отсутствие встроенного пакетного менеджера. Можно, конечно, через pkgutil --files com.teamviewer.teamviewer10
смотреть, что и куда установлено, и удалять руками… А можно пользоваться homebrew, macports и иже с ними, которые более-менее решают эту проблему для софта из репозиториев. Возможно, есть решения и для чистого удаления сторонних .pkg-шек, но я не искал.
Проблема в скриптах пре- и пост-установки, которые могут быть в pkg (ради которых pkg и делают, собственно), причем скрипты не обязательно написаны на shell — это могут быть вообще произвольные бинарники, внутрь которых заглянешь только дизассемблером. Поэтому в общем случае макось не знает, что они творят, и в --files не вносит. Как вариант, решается это виртуализацией процесса установки, чтобы перехватить все операции над ФС и defaults, но в Apple по какой-то причине не стали заморачиваться. Может быть, кто-то заморочится?
Ну, чисто теоретически, опять же, можно поверх mach нахреначить гипервизор… Позаворачивать все сисколлы на гипервизор, а оттуда в юзерспейс перекидывать лог действий. Но у меня что-то руки немного опускаются от перспектив подобных извращений — причем я даже не уверен, не работает ли ядро УЖЕ на -1 кольце, или не занимают ли его проги типа Parallels. Вроде ведь как делать цепочки гипервизоров пока нельзя?
Решения нет — я искал, ужасался.
честно говоря подобное немного ставит в ступор, непонятна позиция apple.
Из действенных — ставить из псевдорепозиториев — homebrew, macports.
Да не псевдо они, вполне настоящие — как минимум, homebrew. С макпортами плотно не работал, за них сказать не могу. Или почему вы их "псевдо" считаете?
А по поводу решения — может, раз уж Эппл пошла копать в направлении сэндбокса системы, то в 10.12 будет песочница для произвольных приложений? Сейчас песочницы для приложений из стора уже есть, но толку от них.
Да и всеравно это не решит проблему взаимосвязи приложений, только еще больше может раздуть дистрибьютивы приложений (вообще в маке на мой взгляд самый большие дистрибьютивы, т.е. блокнот весящий 100мб это вполне норимально для мака)
А, ну и стоит отдельно отметить, что пакетные менеджеры в Линуксе, например, не ведут учет файлов, которые были созданы после того, как пакет был установлен. Поэтому если пакет не говорит, как именно его деинсталлировать, этот мусор останется висеть.
С программами в Windows та же ситуация — если деинсталлятор предпочтет что-то оставить в системе (какую-то расшаренную библиотеку, или лицензионную информацию) — он их оставит.
Маки в этом плане не исключение.
Впрочем всегда найдутся исключения.
ха… если бы. Всякие скрипты конфигурирования пост-установки срут и в /etc, и в /var, и демонов прописывают, и чужие конфиги меняют… А потом удаляешь пакет, и оказывается, что какой-нибудь nginx делал include какого-нибудь hhvm, и приехали.
Репозиторий это тот же сайт, который просто напросто понятен консольной утилите
В обычном случае нет
Точно так же нужно искать репозитории, если нужно что-то поставить
Не нужно. У меня включены только официальные + несколько ну очень популярных. Если в них чего-то нет, я сама сделаю пакетик, используя спек из src.rpm «палевного» репозитория(проверив его!), и тарболл с сайта автора программы.
Snap-пакеты теперь будут доступны во многих дистрибутивах Linux (а в будущем, возможно, и в Windows)