LINUX.ORG.RU
Форум — Talks  

Snap таки взлетает

 , , ,


0

0

Компания Canonical объявила о реализации поддержки технологии самодостаточных пакетов snap для дистрибутивов, отличных от Ubuntu. Кроме Ubuntu, возможность использования пакетов snap теперь предоставлена для Fedora, Arch Linux и Debian, а сам snap позиционируется в качестве универсального формата пакетов для поставки приложений, не связанных зависимостями с остальными компонентами дистрибутива. В стадии проверки находится реализация snap для CentOS, Elementary, Gentoo, Linux Mint, openSUSE, OpenWrt и RHEL.

https://www.opennet.ru/opennews/art.shtml?num=44601

Репозиторий доступен через веб и консольную утилиту. Пакеты - самодостаточные образы, которые работают в режиме изоляции от ОС, но тем не менее имеют прямой доступ к графической подсистеме.

Из уже поставляемых в форме snap-пакетов программ отмечается графический редактор Krita, САПР FreeCAD, СУБД Cassandra, система непрерывной интеграции Jenkins. Готовятся к выпуску snap-сборки Firefox. Ведётся работа по адаптации приложений KDE для работы со snap и flatpak (бывший xdg-app).

Deleted

Последнее исправление: Deleted (всего исправлений: 1)
← (Полиглотам) Запоминание информации на разных языках - особенности мозга, или у всех так?
Почему appimage не широкораспространен? →
  1 2 3 4 →

самодостаточных пакетов snap
Gentoo

Но зачем?

Deleted
()
Ответ на: комментарий от next_time

А вот список зависимостей.

libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libpthread.so.0()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libgcc_s.so.1()(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libglib-2.0.so.0()(64bit)
libX11.so.6()(64bit)
libgobject-2.0.so.0()(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libz.so.1()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
libstdc++.so.6(GLIBCXX_3.4.15)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
libc.so.6(GLIBC_2.17)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
libxcb.so.1()(64bit)
libXext.so.6()(64bit)
ld-linux-x86-64.so.2()(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libGL.so.1()(64bit)
libdbus-1.so.3()(64bit)
libfreetype.so.6()(64bit)
libgstreamer-1.0.so.0()(64bit)
libasound.so.2()(64bit)
libasound.so.2(ALSA_0.9)(64bit)
libfontconfig.so.1()(64bit)
libpulse.so.0()(64bit)
libpulse.so.0(PULSE_0)(64bit)
libstdc++.so.6(CXXABI_1.3.1)(64bit)
libc.so.6(GLIBC_2.9)(64bit)
libasound.so.2(ALSA_0.9.0rc4)(64bit)
libc.so.6(GLIBC_2.6)(64bit)
libXrender.so.1()(64bit)
libpthread.so.0(GLIBC_2.3.3)(64bit)
libc.so.6(GLIBC_2.10)(64bit)
libexpat.so.1()(64bit)
libICE.so.6()(64bit)
libudev.so.1()(64bit)
libudev.so.1(LIBUDEV_183)(64bit)
libstdc++.so.6(GLIBCXX_3.4.14)(64bit)
libgstbase-1.0.so.0()(64bit)
libcups.so.2()(64bit)
libstdc++.so.6(GLIBCXX_3.4.10)(64bit)
libSM.so.6()(64bit)
libm.so.6(GLIBC_2.15)(64bit)
libstdc++.so.6(GLIBCXX_3.4.18)(64bit)
libgstvideo-1.0.so.0()(64bit)
libXfixes.so.3()(64bit)
libcurl.so.4()(64bit)
libXi.so.6()(64bit)
libgstpbutils-1.0.so.0()(64bit)
libXrandr.so.2()(64bit)
libXcursor.so.1()(64bit)
libgcc_s.so.1(GCC_4.0.0)(64bit)
libgstapp-1.0.so.0()(64bit)
libXcomposite.so.1()(64bit)
libcap.so.2()(64bit)
libnspr4.so()(64bit)
libEGL.so.1()(64bit)
libX11-xcb.so.1()(64bit)
libXtst.so.6()(64bit)
libXdamage.so.1()(64bit)
libgcc_s.so.1(GCC_3.4)(64bit)
libnss3.so()(64bit)
libnss3.so(NSS_3.2)(64bit)
libnss3.so(NSS_3.3)(64bit)
libXss.so.1()(64bit)
libsmime3.so()(64bit)
libharfbuzz.so.0()(64bit)
libxcb-shm.so.0()(64bit)
libxcb-keysyms.so.1()(64bit)
libxcb-randr.so.0()(64bit)
libxcb-shape.so.0()(64bit)
libplc4.so()(64bit)
libsmime3.so(NSS_3.2)(64bit)
libnss3.so(NSS_3.12)(64bit)
libnss3.so(NSS_3.4)(64bit)
libnss3.so(NSS_3.7)(64bit)
libnssutil3.so()(64bit)
libxcb-image.so.0()(64bit)
libxcb-render.so.0()(64bit)
libxcb-xfixes.so.0()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.2.5)(64bit)
libnss3.so(NSS_3.10)(64bit)
libnss3.so(NSS_3.11)(64bit)
libnss3.so(NSS_3.6)(64bit)
libnss3.so(NSS_3.9)(64bit)
libnssutil3.so(NSSUTIL_3.12)(64bit)
libnssutil3.so(NSSUTIL_3.12.3)(64bit)
libxcb-sync.so.1()(64bit)
libxcb-xkb.so.1()(64bit)
libnss3.so(NSS_3.8)(64bit)
libnss3.so(NSS_3.9.2)(64bit)
libnssutil3.so(NSSUTIL_3.12.5)(64bit)
libxcb-glx.so.0()(64bit)
libnss3.so(NSS_3.11.1)(64bit)
libnss3.so(NSS_3.11.2)(64bit)
libnss3.so(NSS_3.12.3)(64bit)
libnss3.so(NSS_3.5)(64bit)
libxcb-render-util.so.0()(64bit)
libnss3.so(NSS_3.12.6)(64bit)
libnss3.so(NSS_3.14.3)(64bit)
libxcb-icccm.so.4()(64bit)
libnss3.so(NSS_3.12.1)(64bit)
libnss3.so(NSS_3.12.4)(64bit)
libsmime3.so(NSS_3.10)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsLzma) <= 4.4.6-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
petyanamlt ★★★★
()
Ответ на: комментарий от petyanamlt

libGL.so.1()(64bit) libdbus-1.so.3()(64bit) libfreetype.so.6()(64bit) libgstreamer-1.0.so.0()(64bit) libasound.so.2()(64bit) libasound.so.2(ALSA_0.9)(64bit) libfontconfig.so.1()(64bit) libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) libc.so.6(GLIBC_2.9)(64bit)

и чё? они уже должны быть в системе

next_time ★★★★★
()
Ответ на: комментарий от next_time

Что то есть, чего то нету...вот того чего не было и вызвало гиморой с обновлением.

petyanamlt ★★★★
()
Ответ на: комментарий от Deleted

Общие библиотеки должны лежать в системе. Другое дело, что в Линуксах с их бессмысленным и беспощадным зоопарком такое невозможно в принципе.

Общие для приложений пакета. Вот у нас есть word.app и powerpoint.app и куча кода у них одинаковая. Где конкретно это будет лежать? Что за этим следит, если пакетного менеджера нету, а приложения «ставятся» перетаскиванием в папку?

ls-h ★★★★★
()
Ответ на: комментарий от EXL

То есть офисный пакет там не будет тянуть kde-лапшу или gnome-лапшу, а просто будет содержать приложение, которое построено на NS*-фреймворках системы.

Но в офисном пакете же может быть много общего кода для самих приложений пакета. И этот код вряд ли будет в системных фреймворках.

ls-h ★★★★★
()

Так и flatpak тоже. Уже использую для некоторых приложений. Теперь дело за поддержкой wayland в приложениях.

Esteban_Garcia
()
Ответ на: комментарий от alpha

Сделано через ж, короче, как обычно.

Уж лучше AppImage или Flatpak.

Deleted
()
Ответ на: комментарий от alpha

Да, там харкод ubuntu store в клиенте.

И что? Код открыт, поправят.

Ну и код серверной части закрыт.

А почему интересна серверная часть? Пакет самодостаточен, выкладывай на хоть на торрент.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Выложить файл на торрент и сейчас можно. Интересен способ доставки, простая установка и всякие плюшки, чтобы индивидуальный разработчик приложения мог организовать персональный канал обновлений для «простых пользователей».

Ну и формат там насколько я понимаю тоже не особо независимый, под apparmor заточен например.

alpha ★★★★★
()
Ответ на: комментарий от tailgunner

Snap нацеливается на IoT, так что без сервера придется заливать новый код ручками на все лампочки\девайсы. Ни разу не привязывание к закрытому сервису

vrutkovs ★★
()
Ответ на: комментарий от vrutkovs

Snap нацеливается на IoT

Как Core i7?

Ни разу не привязывание к закрытому сервису

Интересно, молодая поросль {гномо,федоро}-фанбоев знает о том, что такое up2date и RHN?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Очень грязно играешь.

RHN не анонсируется как «универсальное решение поддерживаемое всеми дистрибутивами» и притягивать его в эту дискуссию некорректно. Но даже тот же Spacewalk открыт например.

alpha ★★★★★
()
Ответ на: комментарий от alpha

Очень грязно играешь.

Играю так же, как со мной.

RHN не анонсируется как «универсальное решение поддерживаемое всеми дистрибутивами»

Хато RPM анонсировался так. Хотя, ужас какой, зависел от RHN и up2date примерно в той же степени, в какой snap зависит от проприетарного сервера Каноникала.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Молодая поросль осознает что сейчас 2016ый. Ну и молодые не особо признают аргументы в стиле «а у вас негров раньше вешали»

vrutkovs ★★
()
Последнее исправление: vrutkovs (всего исправлений: 3)
Ответ на: комментарий от tailgunner

ужас какой, зависел от RHN и up2date примерно в той же степени

Как владелец пяти rpm-репозиториев и контрибьютор еще трех, никак не связанных и даже соперничающих с Red Hat, скажу что это полная чушь.

alpha ★★★★★
()
Ответ на: комментарий от alpha

зависел от RHN и up2date примерно в той же степени

Как владелец пяти rpm-репозиториев

Так и хочется спросить «Сколько тебе лет? Хорошо ли помнишь RedHat 6.1?».

tailgunner ★★★★★
()
Ответ на: комментарий от vrutkovs

Ну и молодые не особо признают аргументы в стиле «а у вас негров раньше вешали»

Молодая поросль еще и по-русски плохо понимает.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ты сформулируй какую мысль хочешь донести, целиком. Чтобы было о чем говорить.

То что ты многомудрый нелюбитель Red Hat я понимаю, и что доставка пакетов в red hat 6.1 тебе не нравится - тоже. Осталось понять к чему это в этом треде.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

Ты сформулируй какую мысль хочешь донести, целиком. Чтобы было о чем говорить.

Здесь непонятно? RPM (который формат) зависел от проприетарного RedHat-сервиса в той же степени, в которой Snap зависит от проприетарного сервера Canonical. Это не помешало RPM взлететь.

То что ты многомудрый нелюбитель Red Hat я понимаю

Это не мудрость, но я давно в этом ремесле и кое-что помню. A RedHat не лучше и не хуже Canonical, просто методы другие.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ты не с тем споришь.

Я отвечала тебе на слова про «зато работает для любого де», и только.

А про взлетит или не взлетит - трудно сказать. Марк Шаттлворт вон три дня из G+ не вылезает, пиарит лично, всю ленту в Linux-сообществе замостил.

При этом как всегда пиарит в расчете на пользователей и бесит ДЕ-разработчиков и разработчиков дистрибутивов.

Я все еще верю, что с разработчиков пиар начинать правильнее и разумнее, но время покажет. Сейчас чего только не взлетает..

alpha ★★★★★
()
Ответ на: комментарий от alpha

Ты не с тем споришь.

Да? Мне показалось, ты привела закрытый сервер Каноникал как аргумент против Snap, но ладно.

При этом как всегда пиарит в расчете на пользователей и бесит ДЕ-разработчиков

DE-разработчики нимало не колеблются бесить пользователей. Впрочем, это другая тема.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Против snap у меня гораздо более фундаментальные аргументы. Мне просто не нравится «контейнеризация» приложений, в любом виде.

А тут скорее я против подачи этой новости как «универсальное кроссплатформенное решение принятое во все дистрибутивы и DE». Потому что не слишком универсальное, никуда не принятое и весьма пока холодно встреченное причем, не только в Fedora, что понятно, но и в Gentoo-сообществе, например.

И объявлять о поддержке чего-то в дистрибутиве не пройдя даже процесс ревью для добавления пакета в дистрибутив - именно из-за такого пиара Canonical так не любят в сообществах, а не потому что «Red Hat все купил», имхо.

alpha ★★★★★
()
Ответ на: комментарий от alpha

И объявлять о поддержке чего-то в дистрибутиве не пройдя даже процесс ревью для добавления пакета в дистрибутив - именно из-за такого пиара Canonical так не любят в сообществах, а не потому что «Red Hat все купил», имхо.

Почему красношляпные евангелисты такие звезданутые? Реализацию для дистрибутива сделали? Сделали. Сами проверили? Да. Работает? Работает. Стало быть, идите на хрен строевым шагом и с песней.

Valkeru ★★★★
()
Последнее исправление: Valkeru (всего исправлений: 1)
Ответ на: комментарий от alpha

Мне просто не нравится «контейнеризация» приложений, в любом виде.

Да, тенденция печальная. Но, похоже, это dumb idea whose time has come - все этим занимаются.

tailgunner ★★★★★
()
Ответ на: комментарий от Valkeru

Видишь ли, дело вовсе не в наличии или отсутствии шляпы.

Просто дистрибутив - это не набор файлов, которые в день релиза выкладываются на сервер.

Дистрибутив - это структура и сообщество, процесс принятия решений и процесс review, процесс тестирования и процесс релиза, единые packaging guidelines и единые стандарты.

И «дистрибутив поддерживает» - это знак качества, гарантия того, что проект соответствует каким-то требованиям и проверен сообществом. Такими статусами не разбрасываются просто так, их заслужить надо.

Ты можешь в _своем_ проекте поддержать дистрибутив выложив у себя рпмку, но это не значит, что дистрибутив и сообщество должны при этом поддерживать _тебя_.

alpha ★★★★★
()
Ответ на: комментарий от Valkeru

Да мне-то вообще все понятно.

Особенно когда в пресс-релизе распинаются про безопасность и confinement, и как «Snaps already work natively on Arch Linux, Debian, Fedora, and Ubuntu», а потом выясняется что для Fedora не то что дополнительного слоя безопасности вокруг отдельного snap-пакета нет, но и глобально в системе selinux предлагается отключить.

У меня так tar.gz-файлы с gog.com natively работают...

alpha ★★★★★
()
Ответ на: комментарий от alpha

У меня так tar.gz-файлы с gog.com natively работают...

На gog.com давно уже нет tar.gz, перешли на .sh инсталляторы с далее-далее-далее ☹

Psych218 ★★★★★
()
Ответ на: комментарий от alpha

Это победа.

Такое ощущение, что критерии приёма в Canonical и Госдуму приблизительно одинаковы.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 →
← (Полиглотам) Запоминание информации на разных языках - особенности мозга, или у всех так?
Talks
Почему appimage не широкораспространен? →