Компания Canonical опубликовала (https://lists.snapcraft.io/archives/snapcraft/2016-December/...) новый выпуск Snapd 2.20 (https://github.com/snapcore/snapd) (выпуск 2.19 был пропущен), инструментария для управлениями самодостаточными пакетами в формате snap (https://www.opennet.me/opennews/art.shtml?num=44601), а также Snapcraft 2.23 (https://github.com/snapcore/snapcraft/releases), утилит для формирования пакетов Snap. Новые версии включены в состав предварительных сборок Ubuntu Core ("snap refresh --candidate core") и в ближайшее время будет добавлена в штатные репозитории Ubuntu, при этом впервые сборка будет предложена не только в Ubuntu 16.04 и 16.10, но и в Ubuntu 14.04.Основные улучшения:
- Поддержка псевдонимов ("alias"), позволяющих организовать привязку вторичных команд ("$snap.$app") к командам первого уровня, например, использовать mongo32.dump как команду mongodump (полезно, когда в системе одновременно установлено несколько версий пакета, например, mongo26 и mongo32, что приводит к конфликту из-за возможности применения команды mongodump к обоим пакетам);- Обеспечена поддержка Ubuntu 14.04;
- Расширен вывод команды "snap info" (отражено время последней операции, размер пакета, описания и другая информация);
- Повышена надёжность сетевого взаимодействия (задействован более агрессивный алгоритм возобновления проблемных соединений);- Добавлены интерфейсы dbus, network namespaces, i2c и modem-manager;
- Добавлен новый тип ограничений "classic", упрощающий создание пакетов для инструментов, подобных gcc;
- Расширена поддержка delta-обновлений на базе xdelta3, при которых вместо всего пакета при обновлении загружаются только изменившиеся данные;
- Улучшены средства автодополнения ввода через нажатие клавиши табуляция;- Проведено объединения кодовых баз snap-confine и snapd;
- В Snapcraft реализована поддержка FTP в качестве источника, добавлена новая команда "snapcraft enable-ci" для упрощения проверки в системе непрерывной интеграции travis, в базовый состав перенесены средства управления кодом, добавлен слой для формирования delta-обновлений, реализован механизм кэширования.
URL: https://lists.snapcraft.io/archives/snapcraft/2016-December/...
Новость: http://www.opennet.me/opennews/art.shtml?num=45715
Поддержка центоси когда будет?
Опять идут неправильным путем и пилят костыли, пускай уже сольются с GoboLinux, поставят mir по дефолту и будут пилить свою отдельную от linux сообщества(по крайней мере идеологически) систему для тех кто хочет mac без зондов и на халяву.
Я не вникал, но вроде бы уже делается flatpak, зачем ещё и snap? Они будут совместимы? Или Каноникал опять тянет одеялко на себя? Поясните вкратце, пжлст.
> Они будут совместимы?NIHуя не будут.
>Я не вникал, но вроде бы уже делается flatpak, зачем ещё и snap?flatpak, а в девичьи годы xdg-app, нихрена не умел пару лет. И вот, пакетов в snappy стало переваливать за несколько сотен, каноникал начали продвигать это в практику -- активизировались, и добавили в 2016 году тока поддержку пары тяжелых приложений и гном-аппликух. Появились оба примерно в одно и то же время.
flatpak -- lgpl 2.1, snappy - gplv3.
Спасибо.
Только наоборот - уже делается snap, зачем начали ещё и flatpak? Red Hat тянут одеялко.
до тех пор, пока снап прибит гвоздями к убунте - пусть тянут
14.04 -- https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1614587
нужен какой-то инструмен, универсальный для flatpak и snap, что позволит исопльзовать пакеты обеих систем. Можно назвать SnapPak
Вот из статьи про множество универсальных пакетных форматов и их внутривидовую борьбу:"Интересно ещё и то, что практически одновременно с инициативой Canonical аналогичное решение предложила и компания Red Hat. Создаваемый ей универсальный формат пакетов Flatpak претендует на ту же саму роль, что и Snappy. Очень похоже, что есть основания говорить не о технологическом, а корпоративном соперничестве.
Брюс Байфилд обращает внимание на один любопытный нюанс. Соперничество DEB (Debian/Ubuntu) и RPM (Red Hat/Fedora) существует очень давно. Споры о том, какой формат лучше, не утихают и по сей день, хотя накал дискуссий уже не тот, что был в самом начале. Сейчас по сути назревает аналогичный конфликт, только между универсальными пакетами от Red Hat и Canonical.
Причём в данном случае практическая аргументация вряд ли будет носить исключительно технологический характер. Даже беглое знакомство с AppImage, Flatpak, Snappy и GNU Guix позволяет сделать вывод, что все они имеют схожие принципы установки, удаления или обновления.
Конечно некоторые особенности у каждого формата есть. Например, Snappy позволяет установить только изменённую с момента последнего обновления часть пакета, а Guix не исключает использования уже установленных зависимостей. Но несмотря на это нет видимых причин, препятствующих включению в одну систему функций, применяемых в другой."
Про то что это не столько борьба за обычных пользователей, сколько конкуренция за корпоративных:"Универсальный формат пакета — это явно не то, что нужно пользователям Linux в первую очередь. По крайней мере, ничего принципиально нового это не даёт. Так почему же две ведущие компании практически одновременно взялись за решение этой не особенно актуальной задачи?
Возможный ответ — бизнесу важно контролировать одну из основных функций системы. Причём речь может идти о установке не столько свободных, сколько проприетарных приложений, работающих в Linux. И это именно то, за что можно побороться.
Таким образом уместней говорить не о каких-то инновациях, а о фактически прямом столкновении двух компаний: Canonical и Red Hat. Борьба идёт за корпоративного пользователя, который не может решить все свои задачи при помощи исключительно свободного ПО."
Мне вот интересно. Допустим все зашивается в одну папку со всеми зависимостями.Есть у меня 10 программ.
10 программ используют 10 общих зависимостей + свой код.Зависимости весят 50 мб.
1 программа весит 50 мб.Раньше (без Span-подобных) на диске было бы 50 * 10 + 50 мб зависимостей = 550 мб.
Сейчас (со Snap), получается (50 + 50) * 10 = 1000. Т.е. практически в 2 раза больше места на диске тратится.
Пример в вакууме.
Вопрос - вы правда считаете это нормальным?
Никто не тащит все зависимости в пакет - ни снап, ни флетпак. И там и там есть свои common-интерфейсы и плаги. Главные их фичи всё-таки в изолированности и универсальности для всех дистрибутивов. А уже потом в возможности притащить свою либу с собой.
Почему тогда не сделают изолированность и универсальность на уровне ОС? Зачем эти костыли в виде Flatpack, Snap, AppImage и Guix?Надо просто внедрить поддержку на базовом уровне для всех дистрибутивов и готово. Разве нет?
>> Надо просто внедрить поддержку на базовом уровне для всех дистрибутивов и готово. Разве нет?Пробовали. LSB (Linux Standard Base). Не получилось, все куй забили, ищут другой подход.
Место на дисках это еще цветочки. Куда хуже необходимость загрузить кучу копий одной и той же либы в память. Хотя конечно найдуться альтернативно одаренные с расказами о дешевой памяти и нищебродах.
>> Куда хуже необходимость загрузить кучу копий одной и той же либы в память.Зачем?
Попробуй что ли почитать, что собой представляет сабж.
В теории вы правы. Самодостаточный snap должен быть тяжелее deb пакета, но на практике оказалось что из-за сильного сжатия squashfs пакет Krita (для примера) меньше весит чем если бы поставили Krita с её зависимостями традиционно через deb. Вначале пути технологии snap реально много приходилось упаковывать вместе с программой, НО с развитием технологии стало появляться всё больше интерфейсов, к которым можно попросить connect и многое уже не нужно паковать внутрь с программой.
Многие люди не понимают зачем snap рождён. Мир деб пакетов - это discretionary access control, DAC. Deb - это вы поставили программу и она может, наследуя ваши права, "поползать" по вашей папке ~/, так как права доступа это ей позволят. Snap - это Mandatory access control, MAC. Snap - это тюрьма. Snap - это ежовые руковицы, в которых программа может заранее оговорённое и влево-вправо-прыжок-наместе-расстрел.
Больше ли могут занимать пакеты snap? Да, могут. Но воспринимайте это как плату за ещё более усиленную безопасность и независимость программы от системы и наоборот.
Мои snap пакеты в Ubuntu Store
snap find vsДобро пожаловать на мой сайт http://vasilisc.com/ , где я люблю освещать эту тему.
> Snap - это Mandatory access control, MAC. Snap - это тюрьма. Snap - это ежовые руковицы,
> в которых программа может заранее оговорённое и влево-вправо-прыжок-наместе-расстрел.подскажите, если знаете, где можно на русском или простом инглише почитать про эти особенности Snap ?
>> Snap - это Mandatory access control, MAC. Snap - это тюрьма. Snap - это ежовые руковицы,
>> в которых программа может заранее оговорённое и влево-вправо-прыжок-наместе-расстрел.
> подскажите, если знаете, где можно на русском или простом инглише почитать про
> эти особенности Snap ?Чтобы дистанцировать Snap от Ubuntu, сделан сайт http://snapcraft.io/
С него и начинают снапкрафтеры своё знакомство.
Про универсальные форматы от сообществ, а не от корпораций (RedHat, Canonical):"Впрочем совершенно не очевидно, что реальный выбор будет ограничен только двумя решениями, созданными крупными компаниями. Некоторые разработчики вообще не любят иметь дело с корпорациями — они попросту не примут ни того, ни другого, искренне считая, что подобные важные элементы системы должны развиваться только под эгидой какого-либо фонда.
По этой логике у них будет иной выбор: AppImage или GNU Guix. Второй проект предпочтительней тем, что он тесно связан с Фондом свободного программного обеспечения и его участники всячески демонстрируют свою приверженность принципам Open Source. А вот AppImage распространяется на условиях лицензии BSD, которая недостаточно защищает свободу ПО."
И про то что "ОБА ХУЖЕ" - что Snap от Canonicalа, что Flatpack от RedHatа это попытки корпораций навязать сообществу свои стандарты, для того чтобы потом извлекать коммерческую выгоду от корпоративных заказчиков и одновременно при этом держать под контролем сообщество:"Получается, что соперничество в данном случае ведётся не только между двумя крупными компаниями, но и между бизнесом и сообществом, поскольку в данном случае нет полной уверенности, что корпорации будут действовать в соответствии со стандартами сообщества.
Хотя идеология Open Source не отрицает конкуренции, но считает сотрудничество более эффективным способом достижения цели. Поэтому предлагая различные стандарты универсального пакета Canonical и Red Hat фактически подрывают базовые идеи СПО."
https://www.pcweek.ru/foss/article/detail.php?ID=186978
Вывод - по сути они оба одинаково не нужны, и GNU Guix - наше всё.
Корпоративные клиенты нужны лиунксу. Без вливания денег полноценного развития не будет в системе. Будет на уровне "и так сойдет".
А то что у кого то проблемы между 550 метрами и 1 гигом так это его проблемы. Сейчас обьемы дисков позволяют и не такое.
И такие пакеты дадут удобство всем, и юзерам и более знающим.
Проблем нет. Но это как посмотреть. Если у вас SSD, то поймете меня.
Извините но у меня ssd как на компе так и на рабочем ноутбуке. И я не понимаю все равно. и к слову, они работают над snap пакетированием и улучшаюи его работу. Например теперь обнавления идут только для той части что новое. А раньше только весь пакет. Так что ребята понимают и вашу точку зрения и думаю выход будет найден.
Вы не сечете, это большой плюс к секьюрности. В связи с последними новостями это оставляет хоть какую-то надежду на будущее линукса.
Линуксу не хватает дизайнеров. Надо в европу за ними ) У них толерантность, все дела )))
История с Mir/Wayland повторяется?
А что с Mir/Wayland?
что только не делают, лишь бы не nixpkgs