Snap-пакеты из Ubuntu теперь работают и в других дистрибутивах

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

Подсказка: если у тебя на жёстком диске будет 10 копий Qt, то в оперативной памяти и в кэше L2/L3 тоже будет 10 копий Qt. Никакая дедупликация на уровне ФС от этого не спасёт.

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

Ну и что? да хоть по 100мб на приложение, мне не нужно одновременно иметь столько *разных* приложений статически слинкованных с qt чтобы закончилась вся память. А в кеше процессора всеравно будут лежать только отдельные куски кода, так что эффект мизерный.
И вообще я не говорил что динамическая линковка плоха сама по себе. Мне не нравится когда ради нее портят или запрещают статическую. А еще когда ее используют для того чтобы прикрыть недостатки архитектуры. Наговнокодили библиотеку на 100500 мегабайт? не важно, мы ее динамически слинкуем и никто не заметит.

Подсказка: если у тебя на жёстком диске будет 10 копий Qt, то в оперативной памяти и в кэше L2/L3 тоже будет 10 копий Qt. Никакая дедупликация на уровне ФС от этого не спасёт.

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

Ну это так, заметки на полях.

Это, безусловно, так.

Только в контексте сабжа у каждого snap-пакета будет своя копия всех библиотек в том виде, в котором они нашлись у сборщика. У одного будет qt 5.5.2-ubuntu3, у другого qt 5.5.4+git123456-fc24 и так далее (числа с потолка), и это заявляется как фича.

и это заявляется как фича

Это и есть фича, причем самая главная. Ради этого все и сделано. Если разработчик собирал и тестировал свое приложение на 5.5.4+git123456, то мейнтейнеры убунты пусть идут лесом со своим 5.5.2-ubuntu3.

Я правильно понимаю, что пока все остальные дружно пилят безопасные переносимые контейнеры приложений с привилегиями, Шатлворт выложил очередную свою наколенную поделку и пытается предоставить её всем как откровение свыше?

А ksm тут не поможет?

Я за. Помните RPM? Были пакеты для i386, а были для mdk10.i386. То есть пакеты для конкретных дистров, и для всех дистров сразу. Прекрасно же было!"! Был LSB, гарантирующий совместимость одного и того же бинарника между всеми дистрами (если собирать в Red Hat).

А потом появился Ubuntu. RPM стал нафиг никому не нужен. А Ubuntu не давал того, что давал Red Hat: вышла новая убунта - будьте добры подключить обновлённые репозитории. Всё, что было установлено вне них - отваливалось. Кроме собранного в Red Hat, лол, например Flash или драйвер NVIDIA.

Показательный пример - клиентское По для системы видеонаблюдения ТРАЛ. DEB-ки собраны для Ubuntu 10.04, и смог заставить их работать в Ubuntu 12.04 только путём долгого траха. Avcodec, avformat нужны были *.so.48, а в системе *.so.52, и других нет! И ещё три либы по-мелочи.

Не просто же так Valve ушла с убунты: бета-версия была вообще лёгкой, и тесно интегрировалась в систему! При установке новой игры, нам показывали что из репо надо установить вот этот список зависимостей, и gksudo просил пароль root. Но вышла 12.10, и всё рухнуло, как карточный домик. «Эй, Canonical!» «А?» «Ты что, не обеспечиваешь бинарной совместимости между версиями убунты?» «Ну нет, а что кто-то обеспечивает что ли?» «Ну RHEL например!»

Короче, убунта притормозила появление портов ПО с Windows на Linux (и как следствие, рост популярности Linux). Просто потому, что люди не знали как пакетировать! В Ubuntu - отвалится через полгода (если не таскать все либы с собой), в CentOS - да, в нём и надо было. «Вы что, офигели? У нас bleeding edge software, а там все либы старые!». Или вообще «оно на RPM? Не нужно!»

А раз убунта всё сломала, то ей и чинить! Я поддерживаю snap!

// извините за сумбурность

да хоть по 100мб на приложение, мне не нужно одновременно иметь столько *разных* приложений статически слинкованных с qt чтобы закончилась вся память

Билли тоже говорил, что 640K хватит всем.

А в кеше процессора всеравно будут лежать только отдельные куски кода, так что эффект мизерный.

Тут такое дело: граф достижимости функций в GUI-библиотеках достаточно сильно кластеризован. В результате в кэше процессора будет лежать 10 копий одного и того же куска кьюта.

Эта фича не оправдывает ухудшение безопасности и огромное увеличение ресурсоёмкости системы.

Только в контексте сабжа у каждого

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

А сторонние пакеты будут пользоваться чем хотят. В этом, собственно и была цель.

Только вот качать придётся реально много :-)

Я правильно понимаю, что пока все остальные дружно пилят безопасные переносимые контейнеры приложений с привилегиями, Шатлворт выложил очередную свою наколенную поделку и пытается предоставить её всем как откровение свыше?

Нет. Во-первых, Шаттлворт выложил свою поделку в релиз ещё полтора года назад, в то время как безопасные переносимые контейнеры пока ещё полностью не работают ни у кого, во-вторых никто её не пытается представить.

Еще один шаг - и мы возвращаемся к зависимостям.

Я говорил, что Ubuntu - это лидер среди Linux систем. ... А кто сомневается? Тролли, школьники и злопыхатели.

Если что то вжное для меня можно будет делать только в убунту и клонах, это будет значить, что пора уходить с линуксов на винду. Потому что это будут уже не линуксы.

Нужно. Для идиотов-проприетарщиков, которые не осилили нормально собрать по паре deb и rpm пакетов.

К сожалению, у убунты нет нормальных стратегов, которые могут далеко и решительно задвинуть в сообщество подобную технологию. Будет примерно так же как с upstart, потом примерно так же будет с Mir. Редхату достаточно перстом указать на любую конкурирующую Snap технологию и через 1-2 года все эти наработки по Snap не будут нужны даже каноникал.

Ненужно. Говно мамонта ненужно.

А разве кто то делает дедупликацию ФС через жёсткие ссылки? Я как то попробовал написать скрипт, проворачивающий это для указаных каталогов через контрольные суммы. Скрипт работал, но 3 из 4 префиксов вайна в итоге упали. Причём не сразу упали, а при следующем обновлении вайна в системе.

Snap — пакет со всеми зависимостями, работающий в любом поддерживающем Snap дистрибутиве. Он обновляется автоматически

В обход пакетного менеджера? Не нужно.

Это планируется, мы пока обсуждаем отдалённое будущее проекта snap. В настоящий момент никакой дедупликации нет, и, соответственно, место и память расходуются сильно.

В зюзе утилита работы со снепшотами бтрфс зовётся снаппи. Отличный выбор имени.

Работаешь только с одной программой? Вот тебе пример по 100МБ только рантайма (не включая потребление самим прогоаммами) на каждую: plasma-desktop, dolphin (1 or 2 window), okular (1-6 windows), firefox, kicad, inkscape(1-4 windows). Может у тебя и 32 ГГБ оперативки, у меня всего 4. А помимо этого в системе ещё и демоны вертятся, кеши всякие.

Ты считаешь, что названия ни в коем случае не должны никогда дублироваться?

Приколочено к Ubuntu Store, требует регистрации даже для скачивания и установки пакета.

Это СПО? Значит можно и свою снап-репу поднять. А на фиг им регистрация? Тред не читал, может уже ответили.

Каждый снап монтируется как loop-образ, соответственно, все эти примонтированные образы вылазят в файловом менеджере и во всех остальных местах, где отображаются примонтированные устройства. Ладно если снапа всего 2-3, а если 20?

Если взлетит, то в популярных решениях исправят.

Дальше автоматического монтирования образа интеграция снапа в систему не идёт, пердолься как хочешь. Как обычно в убунту, от юзерфрендли - одно название.

Так в этом и смысл — пакет самодостаточен. Или я не правильно понял?

Найдется в libresheto уязвимость, и придется обновлять все snap-пакеты, если вообще разработчики озаботятся выпуском обновлений.

Обратная сторона медали. Вообще, какое-то тупое решение эти снапы. Но может по этому и взлетит.

Возможно, это шаг к устранению такого важного недостатка Линупса, как «дистрибутивы»?

Нет. Оно слишком деревянное.

Так в этом и смысл — пакет самодостаточен

Ну и что? Установкой пакета занимается утилита, почему она не может засунуть те же иконки в меню?

Перепроверил, в сюсе прога называется snapper. Так что ошибся я.

Потому что тот, кто собирает snap-пакет не хочет знать, что там у тебя в качестве «меню» используется.

Любое меню работает с /usr/share/applications или ~/.local/share/applications.

Сегодня работает, завтра нет. Да и не в меню дело, а в подходе.

Правильно, в подходе. Как я убедился, у сабжевой поделки подход традиционный для убунты: через жопное отверстие.

Сегодняшняя реализация деревянная, но в этом ее преимущество. Оно должно работать везде и максимально понятно и прозрачно для разработчика. И тут лишние переусложнения не нужны, иначе теряется смысл.

Извлечь из снапа иконку и положить её по известному пути ФС это переусложнение? Ясно. Понятно.

Это избыточно. Ведь задача снапов работать на любой конфигурации, а твои иконки лезут в хост систему. И не факт что они будут работать (причины сам придумай).

Ну я так и говорю: под флагом упрощения и облегчения использования в очередной раз заставить пользователя пердолиться вручную. Прям фирменный дух Canonical.

задача снапов работать на любой конфигурации

А у меня в системе может не быть твоей «папки под иконки». Так что тут мне все нравится в реализации.

А у меня в системе может не быть твоей «папки под иконки»

Только если вы вендузятник.

Да мало ли. Вон на LSB клали даже в дебиане. Что еще через год будет одному богу известно, а снап должен работать. Иначе он на фиг не нужен.

Вот тебе пример по 100МБ только рантайма

кстати, ЕМНИП snap пакеты позволяют использовать системные предустановленные библиотеки (например, GTK, glibc), а остальное тащить с собой. в этом случае ведь не будет 100 МБ, так?

Может у тебя и 32 ГГБ оперативки, у меня всего 4. А помимо этого в системе ещё и демоны вертятся, кеши всякие.

ты это написал, потому что полагаешь, что кто-то будет каждый системный демон или утилиты типа bash или sed в снапы паковать?

Не. Я просто не согласен с тем, что лишний рантайм это фигня. Это кажется что мелочь, но из такой мелочи обычно много набегает. И я даже буду рад появлению такого формата, как снеп. Туде можно запхать свежую версию фаерфокса, торбраузер, тестовые билды прог, которых нет в репах. Я только за. Но боюсь, что некоторые могут сильно увлечься. Да, баш будет не в снепе. Но нельзя быть уверенным, что никому не придёт в голову запхать в снеп свежий кде. А я, как нищеброд, буду страдать.

Во всём ПО могут даже не обновить libresheto до следующего релиза.

А если 20, то надо вынуть руки из одного места и осилить пакетный менеджер.

Лучше бы так там и оставалась.

Нет. Предполагаемый метод куда хуже, т.к. таскает за собой паровозик, из которого нубы что-то да удалят руками.

Зато родится фундаментальный недостаток оффтопика.

А теперь будет больше багов в софте и библиотеках. Т.к. авторы библиотек подзабьют на обратную совместимость, а разработчики начнут активно использовать недокументированные возможности.

Windows

А зачем Snap портировать в Шindows?

Работаешь только с одной программой? Вот тебе пример по 100МБ только рантайма (не включая потребление самим прогоаммами) на каждую: plasma-desktop, dolphin (1 or 2 window), okular (1-6 windows), firefox, kicad, inkscape(1-4 windows). Может у тебя и 32 ГГБ оперативки, у меня всего 4. А помимо этого в системе ещё и демоны вертятся, кеши всякие.

Няшечки-поняшечки, извольте предоставить разработчикам единый, стандартный, обратно совместимый набор библиотек. в пределах одного выпуска ОС, года так на 4.