LINUX.ORG.RU
ФорумTalks

Ох эти странные новые пакеты...

 , ,


0

2

Давайте поговорим о Snap(py), FlatPak и AppImage!

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

chmod +х *.AppImage
и можно запускать. Но кто гарантирует*, что оно запустится? В отличии от первых двух тут нет никаких зависимостей, никто не знает, будет ли на целевой системе нужная библиотека. И вообще это просто спецификация (да, есть эталонная реализация), в которой так и написано, что надо нацеливаться на наиболее старые версии дистрибутивов и всё носить с собой. Вопросы безопасности в AppImage никак не решаются и оставлены на усмотрения пользователя и применение стороннего ПО (Firejail). С одной стороны пользователь сам должен понимать, что он скачивает и что запускает. С другой - AppImage позиционируется именно как простой для пользователя, неискушённого терминалом, способ скачать ПО и сразу его запустить. Создатель AppImage (ник probonopd) явно фанатеет от macOS и их подхода установки программ с помощью перетаскивания бандла (директория с расширением ".app") из архива в «/Applications». Кстати, что забавно, у пользователей macOS это вызывает большие трудности и они знают 1000 и 1 способ как сделать это неправильно. Проблема с безопасностью не только в, что от пользователя требуются дополнительные знания, но и в том, что применение стороннего решения не всегда работает гладко. И это при том, что именно Firejail рекомендуется на главной странице AppImage. Существуют так же и другие небольшие трудности, вроде интеграции с рабочим столом или автоматических обновлений, но это решается установкой дополнительного демона. Хотя при этом концепция становится уже не такой красивой, как изначальное «перетащил, запустил».

Snap. В основном я им и пользуюсь, т.к. стоит Ubuntu 20.04 и это способ установки ПО по умолчанию в приложении Software**. В отличии от предыдущего варианта, тут есть зависимости и разработчик ПО имеет гарантию (наверное), что его ПО будет работать, если они удовлетворены. Есть также изоляция приложений. Но она несколько странная и достаточно слабая. У некоторых приложений можно изменить список прав (да и вообще посмотреть), у других - нельзя. Нет доступного и ясного объяснения, что при этих изменениях происходит под капотом. Ввели новые термины, вроде «Interface», «Plug», «Slot». Но что оно делает внутри? Монтирует разные директории и файлы устройств, меняет профили AppArmor или что? Я пока точного описания не нашёл. Нет нормальной интеграции этого всего с Software. С виду описание разных приложений может ничем и не отличаться, но если посмотреть с помощью
snap run --shell soft-name
изнутри snap-контейнера, то права доступа к файлам и каталогам различаются, и одно приложение получает «Permission denied» там, где у другого всё хорошо. Понятно, что всю это информацию можно получить с использованием консольных команд, но я за прозрачные и изучаемые системы. Даже Android при установке приложения выводит больше информации о требуемых правах доступа и позволяет их менять при первом использовании. Кажется, относительно недавно snap сделал шаг в правильном направлении и интегрировал xdg-portals, которые изначально появились во FlatPak. Это такой способ получения доступа к, например, файлам, когда пользователь видит обычный для него диалог открытия/сохранения файла и выбирает файл, но при этом диалог является отдельным демоном вне контейнера и по результатам выбора управляет доступом для приложения внутри. И это правильный шаг. Но я пока не видел snap приложений, которые это используют. И раз уж приложения запускаяются в некой песочнице, что мешало её сделать более полноценной, ближе к тем же LXC? Чтобы изнутри приложение не просто было ограничено в доступе к определённым файлам, а не видело их в принципе, так же, как и другие процессы. Кроме этого мне очень не нравится, как snap-приложения запускаются. Очень медленно! Хотя их образы всегда смонтированы. Из-за этого вывод информации консольными утилитами (mount, df, ...) сильно захламлён и читать его неудобно. Кстати, зачем? Для интеграции с рабочим столом разве не было бы достаточно копирования .desktop-файлов и подобного наружу? А ещё интересно, как у snap-а с установкой приложений извне магазина от Canonical и просто из скачанного файла? Похоже, что никак. Software по двойному клику на .snap открывается, но сообщает, что установить не в состоянии.

И, наконец, FlatPak. С ним я пока сталкивался недостаточно много, а внутрь заглядывал ещё меньше. На первый взгляд изоляция устроена более полноценно и работают те самые порталы. Хотя, пишут, всё это обман и не работает нормально. По пока неизвестной мне причине запуск приложений из FlatPak происходит быстрее, чем Snap (пробую на одной и той же Ubuntu 20.04). И, насколько я понимаю, магазинов (или их аналогов) тут может быть сколько угодно.

Написал я всё это с целью узнать впечатления других пользователей о данных технологиях, получить более точные и правильные описания процессов, скрытых от глаз, поговорить о достоинствах и недостатках. Может быть есть другие альтернативы, о которых я не знаю?

Интересно, насколько вообще нужно было создавать тот же Snap (или FlatPak) с нуля? Можно ли было использовать apt+dpkg? И тут и там есть пакеты, есть зависимости, действия, которые нужно выполнять при установке и удалении. Можно же было сделать отдельную директорию с отдельной базой для «толстых» пакетов, а управлять ими с помощью существующих средств?

А может быть всё это пути не в том направлении и будущее за NixOS/GUIX и подобными системами с более продвинутыми пакетными менеджерами?

* - предвижу ответ «На GNU/Linux тебе никто ничего не гарантирует, неосилятор!»
** - Как раньше было хорошо с уникальными необычными именами. А теперь «Software», «Files», «Text Editor», «Viewer». Даже в macOS названия и то более разнообразные.

★★★★★

Последнее исправление: ls-h (всего исправлений: 11)

одно приложение - один файл

ну эээ... это не должно быть главным козырем. нет-нет-нет. если это главное и основное, то добро пожаловать в 2010, SLAX, там реализован такой же метод установки пакетов. там вся система разделена на отдельные контейнеры, обычные SquashFS образы, которые монтируются общим OverlayFS (AUFS на тот момент) и накладываются друг на друга. то есть в корне, вся система это условно 3 файла: base, xorg, firefox, но если пользователь сделает find / из системы, он увидит обычную систему. однако пользователь качает новую версию firefox.squashfs, заменяет её в корне, активирует прямо на лету, подмонтирует в overlay, и получает новую версию пакета. или новый пакет, если хочет wine допустим. тоже одним файлом скачал-установил. всё это реализуется скриптами баш и 2 опциями ядра которые сегодня идут уже из коробки (squashfs/overlayfs).

я сам использую аналогичный метод в своём проекте [Комплекс загрузочных скриптов boobstrap], сделаю вырезку оттуда:

mkinitramfs `mktemp -d` \
  --overlay chroot-crux-core/ \
  --overlay chroot-crux-xorg/ \
  --overlay firefox-bin/ \
  --overlay libreoffice/ \
  --overlay fvwm/ \
  --overlay /home/username \
  --overlay /root \
  --squashfs-xz \
  > initrd.img

ничего не напоминает? а это оно самое.

единственное что, я ещё не сделал установку новых .squashfs «на лету», чтобы ты сидишь в системе, скачал .squashfs с нужным условным тебе firefox, и прямо тут-же активировал его.

повторюсь, «одна программа — один пакет» это всё было в 2010 году в SLAX, сейчас это делается тремя строчками на POSIX shell.

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

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

Враньё же. Не вижу принципиальной разницы в этом плане между flatpak и snap.

Модульные рантаймы. Нужен - ставь. Не нужен - не ставь (точнее флатпак сам поставит).

Тоже какая-то сказка из серии теоретизма. Если я ставлю telegram из flatpak, то на наверни ещё больше 1ГБ КДЕ в придачу. Вот такая вот модульность. Естественно ещё рантаймы KDE версии имеют 😀

Раньше telegram в snap не тащил KDE, теперь тащит. Размеры всего это сам можешь оценить и сравнить, но точно твоих сказок о «неприличных размерах в snap, и тонюсенького flatpak» - не будет.

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

У него невнятный CLI — Flatpak и выразительнее, и по фичам вперёд ушёл.

Ищу аналог snap download. Не могу найти…

Делаю в стандартном окне терминала команду информации. По дефолту оно не большое открывается,

flatpak search telegram
Na… Полное опис… Application ID Версия Ветка  Remotes
Fe… RSS client … …me.FeedReader 2.11.0 stable fedora

Скукожено всё. Расширяю - а не, всё - «потрачено». Это же точки. Перезапускай команду.

Хочу информацию о пакете:

flatpak info org.telegram.desktop
ошибка: org.telegram.desktop/*unspecified*/*unspecified* not installed
fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)

Опенсорсные программы можно собирать индивидуально под каждый дистрибутив Linux. А такие веб-сервисы, как OBS, позволяют собрать сразу под 6 дистрибутивов 5 версий. Программы с закрытым исходным кодом следует собирать под промышленный стандарт RHEL/CentOS, например 6 версии. С этим дистром сохраняют совместимость все остальные дистрибутивы Linux на уровне спецификации LSB. Собрав под CentOS 6, запустить под другой дистрибутив Linux будет не проблема. Для этого дистра также доступны репозитории библиотек C и C++, новые компиляторы.

Но мы конечно же будем собирать в разных дистрах разных версий, кто во что горазд. А потом удивляться «почему работает не у всех?». На промышленный стандарт мы будем плевать «эта жи центоэс, им же никто не пользуется, и вообще там пакеты RPM, слооожна». И создавать костыли, перечисленные в тегах.

А так вообще будущее за 0install.

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

Собрав под CentOS 6, запустить под другой дистрибутив Linux будет не проблема

конечно проблема.

CentOS 6 может лишь помочь с древней версией glibc, больше он ни с чем не помогает.

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

Не могу найти…

Нема такого, печально.

Хочу информацию о пакете:

Ты хочешь информацию об удалённом пакете.

commagray@Canterlot ~ > flatpak remote-info flathub org.telegram.desktop 

Telegram Desktop - Telegram Desktop messenger

        ID: org.telegram.desktop
       Ref: app/org.telegram.desktop/x86_64/stable
      Arch: x86_64
    Branch: stable
   Version: 2.1.11
   License: GPL-3.0
Collection: org.flathub.Stable
  Download: 23.6 MB
 Installed: 49.4 MB
   Runtime: org.kde.Platform/x86_64/5.14

       Sdk: org.kde.Sdk/x86_64/5.14
    Commit: 2b0c99253eb204cd918cc5d0d2f95626a914272fc59da58944f10abd0305008f
    Parent: 8aa849b1626fe1412ca6f81ba5530672692a0ab905fbf42531015204a131defa
   Subject: Update to 2.1.11 (c4817a63)
      Date: 2020-06-08 11:58:25 +0000

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

А Snap всё ещё невнятен. Если уточнять, в плане управления разрешениями песочницы.

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

flatpak remote-info

О точно. Ну вот надо кучи опций запоминать для разных случаев.

Вот пользуюсь постоянно snap, apt, brew

util info package

Всё - выводи информацию.

Нет надо самому прикинуть, а поставлен ли он или нет. Не нацелено на удобство пользователя и так во всём.

snap info krita
бла-бла
channels:
  latest/stable:    4.2.9.0 2020-04-16 (55) 129MB -
  latest/candidate: 4.2.9.0 2020-04-16 (55) 129MB -
  latest/beta:      ↑                             
  latest/edge:      4.2.9.0 2020-03-29 (55) 129MB -
snap info telegram-desktop
бла-бла
channels:
  latest/stable:    2.1.11              2020-06-08 (1671)  65MB -
  latest/candidate: ↑                                           
  latest/beta:      1.7.12-beta         2019-07-06  (834)  98MB -
  latest/edge:      2.1.11-3-gb412b2141 2020-06-14 (1679) 158MB -
installed:          2.1.11                         (1671)  65MB -

Просто и понятно. Одна опция для обоих случаев, когда поставлено, и когда нет. И видно что в одном случае поставлено и какой канал, а в другом что не поставлено.

Если я brew открою - будет тоже самое.

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

Ну вот надо кучи опций запоминать для разных случаев

Оно по семантике понятно, потому что тут куча репозиториев и org.telegram.desktop может быть больше одного. Snap и Brew централизованы, а Apt на самом деле не лучшим образом справляется, когда у тебя есть взаимоисключащие пакеты из разных репозиториев.

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

Семантика-семантикой

Нету и близко этакого доведения до блеска. Итак сойдёт.

Например, постоянно как надо выводить скорость или проценты — что попальские значения норма. Задача на 777% готова.

Или там покажем «DONE!» а ещё секунд тридцать (на мощном железе думаем чего-то) и не даём ввод. Я по первой даже испугался, что чего-то внутри глюкануло и застопорилось. Теперь то знаю, что норма.

Ну так бы и писали «Almost done…»

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

доведения до блеска

Толку от этого блеска только? =/ Минорные косяки Flatpak исправят, а более глобальные дизайнерские решения Snap вряд ли.

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

Не только с Glibc. Собирать с более старыми версиями библиотек тоже бывает полезно в плане максимального охвата поддерживаемых дистрибутивов. Бывает по-разному. Например, собирать со старым Boost нет смысла, лучше притянуть новый из EPEL. А собрать со старым Xorg и GTK есть смысл. И вот почему.

Например, пытаясь запустить новый Google Chrome в старых линуксах, он не нашёл какой-то вызов в libXfixes. Пытаясь запустить Transmission, собранный с более новым GTK, я наблюдал то же самое.

Когда я компилировал программы, компилятору было не важно, какой GTK я ему подсовываю: 3.4 или 3.10. Но если я компилировал с 3.10, а запускаю с 3.4, тогда ругается на отсутствие какого-то вызова, а если наоборот, тогда всё прекрасно. Это называется обратная совместимость. А когда можно компилировать с новой библиотекой, а запускать со старой, тогда прямая совместимость.

Это потому что в том же GTK иногда меняют одни вызовы на другие, но старые не удаляют, а оставляют им для обратной совместимости со старыми бинарниками, собранными с более старым GTK. А удалять старые вызовы будут в GTK+4, вместе с переименованием библиотек (цифру сделают на один больше).

Хотя бывает, что компилятор не хочет принимать старый GTK. Например в одном проекте явно поменяли старые вызовы на новые, в преддверии подготовки к GTK+3. Таким образом, повысили требования к GTK с 2.10 до 2.24. И чтобы собрать в CentOS 6 (где 2.18), мне пришлось заменить вызовы вида:

gtk_widget_set_tooltip_text(w, dialog_message(idc));

на:

GtkTooltips *tooltip = gtk_tooltips_new();
gtk_tooltips_set_tip(tooltip, w, dialog_message(idc), NULL);
ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от fornlr

К чему это вообще? Чейнжлоги в другом месте находятся. На дворе 2020 год, Flatpak версии:

commagray@Canterlot ~/Downloads [1]> flatpak --version
Flatpak 1.7.2

С каждым мажорным релизом много интересного.

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

Но стабилизировался он недавно только. Wayland тоже много лет, но реализации только в последние года три-четыре нормальные появились.

Алсо, в исправлениях Flatpak 1.7.2:

This fixes some regressions in progress reporting in 1.7.1, where it would report > 100%.

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

Не вижу принципиальной разницы в этом плане между flatpak и snap.

В snap приложение -это просто тарболл, там нет дедупликации с рантаймом \ другими приложениями.

В flatpak - это набор ostree коммитов, соотвественно второй раз файлы из рантайма \ общей базы (например для electron) не качаются и сохраняются на диске

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

Так речь об экономии трафика? Тоже не вижу такого.

Там эти рантаймы по гигабайту только так летят.

На наверни обновления трёх рантайм KDE штук для телеграмма на гигабайт. И качаться это будет медленно.

Я же и то, и то на практике вижу. FlatPak только в этом году перестал использовать — надоело, только возни, а смыла около нуля.

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

Не знаю. Я это всё выкинул в этом году.

Качается всего очень много и медленно.

С трудом верю, что в пустую, и потом каким-то волшебством это ужимается.

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

В snap приложение -это просто тарболл

Если точнее, то файловая система squashfs.

там нет дедупликации с рантаймом \ другими приложениями.

А между рантаймами должна быть дедупликация? Что-то я такого не наблюдаю:

$ cd /var/lib/flatpak/runtime
$ ls -l org.freedesktop.Platform/x86_64/19.08/active/files/bin/|head
total 46080
-rwxr-xr-x 3 root root   63840 янв  1  1970 [
-rwxr-xr-x 3 root root    3075 янв  1  1970 addgnupghome
-rwxr-xr-x 2 root root   30976 янв  1  1970 addpart
-rwxr-xr-x 3 root root    5227 янв  1  1970 affixcompress
-rwxr-xr-x 2 root root   73112 янв  1  1970 agetty
-rwxr-xr-x 2 root root   18608 янв  1  1970 analyseplugin
-rwxr-xr-x 2 root root   18696 янв  1  1970 analyze
-rwxr-xr-x 2 root root  557104 янв  1  1970 aomdec
-rwxr-xr-x 2 root root  611232 янв  1  1970 aomenc
$ ls -l org.gnome.Platform/x86_64/3.36/active/files/bin/|head
total 80920
-rwxr-xr-x 3 root root    63840 янв  1  1970 [
-rwxr-xr-x 3 root root     3075 янв  1  1970 addgnupghome
-rwxr-xr-x 2 root root    30976 июн 12 01:16 addpart
-rwxr-xr-x 3 root root     5227 янв  1  1970 affixcompress
-rwxr-xr-x 2 root root    73112 июн 12 01:16 agetty
-rwxr-xr-x 2 root root    18608 июн 12 01:16 analyseplugin
-rwxr-xr-x 2 root root    18696 июн 12 01:16 analyze
-rwxr-xr-x 2 root root   557104 июн 12 01:16 aomdec
-rwxr-xr-x 2 root root   611232 июн 12 01:16 aomenc
$ stat --printf="%i\n" org.gnome.Platform/x86_64/3.36/active/files/bin/agetty 
3817078
$ stat --printf="%i\n" org.freedesktop.Platform/x86_64/19.08/active/files/bin/agetty 
2626191

Зачем вообще в рантайме Gnome agetty?

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

то добро пожаловать в 2010, SLAX

Это вот это, да http://www.slax.org? А почему в 2010? Вроде проект шевелится и записи в блоге у них от прошлого года есть? Или они изменили архитектуру и пакеты теперь другие?

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

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

видимо автору надоело тянуть проект, и он решил лениво ковырясь в носу пилить очередную убунту-сборочку на дебьяне :)

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

У снапа некоторые вещи идут на уровне кода и никак не конфигурируются.

Например хомяк не находится в /home/$USER - иди нафиг.

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

А между рантаймами должна быть дедупликация? Что-то я такого не наблюдаю:

Ты не туда смотришь. Одинаковые файлы разных рантаймов/приложений лежат на диске только в одной копии, остальное хардлинки. Скажем так, два рантайма на диске занимают меньше места, чем сумма их размеров.

Каждый в отдельности:

$ du -shcl org.freedesktop.Platform/x86_64/19.08 org.gnome.Platform/x86_64/3.36 org.kde.Platform/x86_64/5.14
694M	org.freedesktop.Platform/x86_64/19.08
954M	org.gnome.Platform/x86_64/3.36
963M	org.kde.Platform/x86_64/5.14
2,6G	итого

Все вместе:

$ du -shc org.freedesktop.Platform/x86_64/19.08 org.gnome.Platform/x86_64/3.36 org.kde.Platform/x86_64/5.14
631M	org.freedesktop.Platform/x86_64/19.08
429M	org.gnome.Platform/x86_64/3.36
285M	org.kde.Platform/x86_64/5.14
1,4G	итого
gasinvein ★★★
()
Последнее исправление: gasinvein (всего исправлений: 1)

Snap можно ставить только от рута, Flatpak – можно и от пользователя. Ещё заметил интересную особенность у реммины из снапа, при первом запуске она просит дать какие-то команды, видимо, какие-то разрешения. Ещё у одной программы из снапа заметил особенность – не было доступа к файлам не в хомяке. Как лечить не понял.

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

А что то, что то…

Вообще все эти штуки GUIX, NixOS, Flatpak такое ощущение что делают чисто ради процесса.

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

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

Ну если тебе так интересно моё мнение, то.

Appimage не умеет сам обновляться. Т.е. закидывать файлик в ~/bin это прикольно, но за обновлениями следишь сам, это не прикольно.

Snap монтируется read-only, поэтому в случае каких-то проблем при опакечивании, можно сосать лапу. В Draktable, например, старая база lensfun, я бы её обновил, если бы можно было писать в сам snap.

Flatpak в этом плане более гибкий, хотя все твои изменения потрутся при последующем обновлении, можно наколхозить скрипт.

Также в snap и flatpak мне не нравится то, что разработчики пошли решать космического масштаба задачи — одновременно и система распространения софта, и система его ограничения. В результате то там то тут натыкаешься на ограничения самого формата. Например, та же самая Darktable и snap или Flatpak не может увидеть поддержку OpenCL в системе — и это не предусмотрено технически. Невозможно сделать интеграцию софта друг с другом.

Да, с ростом версий софта уровень интеграции растёт, но пока что далеко не идеален.

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

Ну если тебе так интересно моё мнение, то.

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

Appimage не умеет сам обновляться

Кажется, там есть специальный демон. Надо посмотреть подробнее...

одновременно и система распространения софта, и система его ограничения

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

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

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

Наверное. А нужны ли они? Вот есть PPA, там нет никаких ограничений, и никто не умер.

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

Кажется, там есть специальный демон. Надо посмотреть подробнее…

Я слышал об этом специальном демоне, но ни разу не видел его в дикой природе. Дай знать, если накопаешь )

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

А за каким хером нужны танки в Арктике, ты не расскажешь?

Вот за этим

The American Interest (США): Арктика американская, а не российская

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

Знаешь что такое меморандум? Это всего лишь сообщение о намерениях.

Вот чтобы намерения не воплотились в жизнь, нам и нужны танки в Арктике

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

Так там ведь всё примерно то же самое, только язык не столь ограниченный. Я скорее про концепцию «разложить все зависимости так, как удобно ОС, изменить соответствующим образом прикладное ПО и, в конечном итоге, получить систему без дублирования и конфликтов» против «запихнуть все зависимости в одну большую коробку, и сделать коробке толстые стенки, чтобы избежать конфликтов».

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

А нужны ли они?

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

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

Достаточно Северного флота и авиации ВМФ. У пиндосов там авиации базироваться негде, поэтому они и не полезут.

Да и само это притянуто за уши. То что газотурбинный танк через 50 лет где-то пригодился - чистая случайность, и никак не оправдывает зоопарк. Если газотурбинный танк так уж нужен, значит надо делать Т-72Д (дизельный) и Т-72ГТД (газотурбинный), а не 3 разных танка.

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

Были. И ограничения от описываемых проблем никак не спасают.

Aceler ★★★★★
()

Концепция репов с треском провалилась, все эти снапы просто попытка залатать дыры. Большинство программистов надо отправить обратно в дворники.

theurs ★★
()

Кстати, насчет жручести flatpak. Только что установил недавно вышедший foliate:

$ flatpak install com.github.johnfactotum.Foliate
Looking for matches…
Found similar ref(s) for ‘com.github.johnfactotum.Foliate’ in remote ‘flathub’ (system).
Use this remote? [Y/n]: y

com.github.johnfactotum.Foliate permissions:
    ipc      network      fallback-x11      pulseaudio     wayland     x11     dri     dbus access [1]

    [1] org.freedesktop.Flatpak


        ID                                                Branch            Op            Remote            Download
 1. [✓] com.github.johnfactotum.Foliate.Locale            stable            i             flathub             2.5 kB / 170.9 kB
 2. [✓] com.github.johnfactotum.Foliate                   stable            i             flathub           942.9 kB / 1.6 MB

Installation complete.

Подозрительно мало скачалось, но он запустился и работает. Гтк и другие flatpak-рантаймы у меня конечно уже были установлены для других flatpak. У кого есть убунта со snap проверьте сколько там качает ( https://snapcraft.io/foliate ). Плюс, у меня установлен foliate предыдущей версии из репов рача, но не думаю, что это как-то влияет.

Ну и в целом, могу сказать, что уже сейчас flatpak работает вполне сносно: запускается быстро, в меню гнома .desktop-файлы добавляет сам, системную тему и шрифты подхватывает, причем даже qt/kde приложения имеют тему adwaita-qt, т.е. выглядит все в одном стиле. Проблем с доступом к ФС нет (снобы, конечно скажут ВОТ ОНА ВАША ХВАЛЕНАЯ БЕЗОПАСНОСТЬ И ИЗОЛЯЦИЯ!). Единственная претензия у меня к нему в том, что слишком мало пакетов, но это постепенно изменится, думаю.

В раче оно, конечно, нужно не особо, я тыкаю его палочкой просто из интереса.

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

Во flatpak, наверное, говорилки нет этой, отсюда и разница. Вообще я предполагал, что в snap будет значительно больше, типа метров 100. Т.е. можно сказать, что страхи о большом оверхеде подобных технологий не сильно оправдываются, каждый калькулятор не будет весить по 100 метров.

Snap, конечно, мне нравится гораздо меньше из-за централизации. В современном мире цензуры, мыслепреступлений и «хейтспича» ложить все яйца в одну корзину просто глупо, мы уже много раз видели к чему это приводит.

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

Я слышал об этом специальном демоне

Оказалось, не демон, вот такая штука есть:
https://github.com/AppImage/AppImageUpdate
На практике пока не пробовал.

UPD:
А демон вот, отдельно:
https://github.com/AppImage/appimaged
Хотя одно с другим интегрируется, но получается решение «наколхозь сам».

ls-h ★★★★★
() автор топика
Последнее исправление: ls-h (всего исправлений: 2)
Ответ на: комментарий от ZenitharChampion

Собрав под CentOS 6, запустить под другой дистрибутив Linux будет не проблема

Ох, какое большое преувеличение. Не только версии библиотек различаются. Даже образы контейнеров нельзя просто так взять и перенести rhel7->rhel8. Либо разрушается контекст безопасности, либо требуются некоторые трюки.

i586 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.