LINUX.ORG.RU
ФорумTalks

Тихо шифером шурша, крыша едет не спеша (у Linux Mint)

 ,


0

1

навеяно вот этим вопросом

Не получается установить snap

Я как-то пропустил этот баян

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

Разработчики дистрибутива Linux Mint заявили, что в грядущем выпуске Linux Mint 20 не будут поставлять snap-пакеты и snapd. Более того, будет запрещена автоматическая установка snapd вместе с другими пакетами, устанавливаемыми через APT.

А откуда ноги растут? В Убунту deb с Chromium - заглушка, которая ставит snapd и хромиум оттуда. И это отличная идея, тут сразу несколько плюсов. Один пакет для всех версий Убунту сразу, какая-никакая изоляция для такого опасного приложения как браузер. Ну и популяризация нормальных пакетов вместо долбаных deb’ов.

А какие контраргументы у Linux Mint?

Недовольство Linux Mint связано с навязыванием сервиса Snap Store и с потерей контроля над пакетами в случае их установки из snap. Разработчики не могут внести исправления в подобные пакеты, управлять их доставкой и проводить аудит изменений.

То есть, в переводе на нормальный язык - из-за snap такие васяны как мы теперь нафиг не нужны и оттого у нас бомбануло. И далее следует поток шизоидного бреда:

Snapd выполняется в системе с правами root и представляет большую опасность в случае компрометации инфраструктуры.

Хахахаха, компрометации. Это говорит линукс минт, у которого официальные образы были скомпрометированы.

Возможность переключения на альтернативные каталоги Snap не предоставляется.

Ну то есть васяны-луддиты больше не нужны. Печаль.

Установка же snapd без ведома пользователя при попытке установки пакетов через пакетный менеджер APT сравнивается с бэкдором, подключающим компьютер к Ubuntu Store.

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

★★★★★

Ответ на: комментарий от Exmor_RS

Вопрос подмены бинарника, упирается в вопрос защиты инфраструктуры

Если скомпрометирована инфраструктура самого дистрибутива, то это проблема будет, да, в любом случае. И даже если весь софт у пользователя будет из snap-пакетов, остаются системные компоненты, как ядро.
Но если это была инфраструктура какого-нибудь gimp, то вероятно это затронет лишь тех, кто скачает сборки с их сайта, т.е. сейчас это windows-сборки. А распространение «самодостаточных пакетов» для линуксов приведёт к тому, что затрагивать будет и линуксы.
А теперь смотри, gimp из пакета с сайта разработчика, libreoffice, firefox, mpv, ещё 9000 программ. И если хоть где-то инфраструктура скомпрометирована, то сразу проблема у пользователей. Причём сразу всех дистрибутивов (пакеты то универсальные).

Самодостаточный пакет решает задачу самодостаточности установщика

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

эталонные суммы пакетов

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

Когда хотят, тогда спокойно внедряют и кейлоггеры и майнеры и что хочешь, мейнтейнеры дистров такие же раздолбаи

Более того, бывает сами мейнтейнеры и внедряют, пусть и ненамеренно, см. древний случай с openssl в debian.
Но суть в том, что в закрытом коде можно внедрять совсем нагло, и обнаруживать и нейтрализовывать это будет сложнее.

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

Согласен. Но если засунуть все зависимости в одни пакет — большинство проблем решаются. Другое дело, как обеспечить возможность делить одну и туже зависимость на несколько пакетов, чтобы избежать оверхеда по дисковому пространству. Это сложней. И если все воткнуть в один пакет, нужно определится, что считать зависимость, а что полноправным пакетом.

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

Можно просто. Пакет делать с полным набором библиотек. Вообще полным.

При установке применять механизм дедупликации на основе хардлинков. То есть просто файлы которые уже есть в системе не копируются повторно а делается хардлинк.

В итоге на диске у нас не будет двух одинаковых файлов.

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

Собственно в Nix уже все это решено, но там сама концепция избыточно сложная.

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

Кое-что интересное предлагал Фрактал, но его идеи требовали хардлинков на каталоги, что сейчас невозможно.

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

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

Но - жто самодостаточный пакет! Теперь я могу модифицировать snapd и использовать содердимое пакета иначе, как мне надо. Не монтировать образ. Добавить дедупликацию. Перепаковать в любой другой, мой экспериментальный формат. Показать людям, что вот можно делать так. А потом, если подход оправдывается, сделать все готовое для пользователей, что заменит снап в текущем виде.

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

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

Qt - это очевидно не все зависимости. Я утверждал что не тянут ВСЁ. Тянут часть. Очевидно по вашим словам что так и есть.

Вот бы ещё крылатое выражение, да ещё и заключённое в кавычки, воспринимать буквально… 🤦

Я в курсе, что не абсолютно всё. Я, как бы, сам об этом говорил, упоминая про core.

Во Flatpak вообще Qt находится в рантайме KDE и ни один пакет приложения его в себе не носит.

Так никто же не носит. Ни Flatpak ни Snap.

Эта проблема ничтожна. Не бэкпортировали - и не надо. Это ни на что не влияет.

«Безопасность не важна»? - так и запишем…

Оптимальным - нет, пригодным для удержания 90%+ рынка в течение почти 30 лет - да. Этого достаточно чтобы как минимум задуматься.

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

Способ пригодный, да, раз им пользуются. И на какие же мысли это вас наталкивает?

А какая разница в данном контексте разговора? Мы обсуждаем не открытость, а подходы к организации ПО в системе.

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

Ubuntu core 20. Для входящих в него библиотек перечислите пожалуйста, какие конкретно патчи вас не устраивают и почему. А то есть подозрение что этот аргумент - пустое балабольство.

Репутация - это не про сейчас, вообще-то. Когда пользовались Ubuntu на сервере, несколько раз попадали на «весёлые» косяки Canonical - см., например, здесь, п. 4.

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

Без проблем? Перечислите пожалуйста, какое ПО вы собираете и опакечиваете и под какие дистрибутивы. Тогда обсудим проблемы (и они есть, причем катастрофические). А то есть подозрения что кто-то просто балабол.

Публичные не собираю. На прошлом месте работы делал deb- и rpm-пакеты, в частности - собственной Lua-библиотеки для работы с оборудованием и её плагинов (которые и реализовывали работу с конкретным типом железок). rpm собирались исключительно под тогдашний CentOS, но практически не использовались; deb собирались для Debian + кросс-компиляция для ARM (RPi), безо всяких проблем ставились и работали в тогдашней Ubuntu LTS.

Большинство доступного открытого ПО присутствует в виде пакетов в основных дистрибутивах. Полагаю, если бы были катастрофические проблемы, как вы утверждаете, то это было бы не так.

(Если вы, конечно, не восприняли «без проблем» буквально как «количество проблем равно нулю». Но тогда вам к доктору.)

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

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

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

Это, почему-то, запрещается великим философом Rootlexx.

Решили попереходить на личности?

P. S. не налегайте особо на проблему дупликации и «тянут всё». Есть целый ряд вариантов по полному устранению дупликации между самодостаточными пакетами. При этом для сборщика они все так же будут содержать всё. Но на диске, и при скачивании - только уникальные файлы, которых нет в уже установленных пакетах.

Я ни словом не заикался про дупликацию, но раз уж вы сами заговорили…

Дедупликация работает, только если в пакетах содержатся абсолютно одинаковые файлы. В контексте библиотек - одной и той же версии и сборки. А поскольку почти каждый пакет snap тащит с собой недюжинное число таких библиотек, и это никак не регламентировано и не стандартизировано, то вероятность того, что в двух пакетах будет использоваться хотя бы одна и та же версия библиотеки (не говоря уже про сборку) весьма мала.

(В flatpak с этим получше, т.к. есть runtime.)

Эта проблема может быть решена технически, и ничего сверхъестественного в этом нет.

Нет, это прекрасно.

Вы не поверите, но проблема одновременной установки разных версий библиотек в рамках традиционных менеджеров пакетов тоже «может быть решена технически». Более того, даже сейчас в том же Debian ничто не мешает поставить одновременно libreadline5, libreadline7, libreadline8.

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

«Безопасность не важна»? - так и запишем…

Да, запишите, желательно на лбу. Проблемы безопасности для десктопа ничтожны. Решая несуществующие проблемы, вы уничтожаете линукс на десктопе. Лечите свою профдеформацию от работы с серверами.

И на какие же мысли это вас наталкивает?

Что вся эта чушь в виде линуксовых репозиториев не нужна пользователю, а только вредна.

Эта модель более-менее успешно работает уже не один десяток лет.

Все развивается. Сложность софта сильно растет. Количество софта сильно растет. Примерно 10 лет назад эта модель себя полностью исчерпала. На настоящее время она не справляется вообще. Это катастрофа. Но чтобы это понимать, надо использовать линукс на десктопе. Не на сервере. Не на картинках. Не для смены обоев или настройки тайлинга. Не для Vim в консоли. Для работы - на десктопе. Тогда все увидите.

Когда пользовались Ubuntu на сервере, несколько раз попадали на «весёлые» косяки Canonical - см., например, здесь, п. 4.

Вы что, не понимаете?

Во-первых причем тут сервер. Мы говорим о линуксе на десктопе. Вы не понимаете, что на сервере совсем другие требования и задачи? Тогда осознайте для начала это. На десктопе работает не админ, а пользователь. Работает не с ограниченным набором серверного ПО, у которого и GUI то нет, а с большим набором десктопного ПО. Осознайте разницу. Я спрашивал не про сервер.

Во-вторых - вы что, не понимаете что ваш пункт 4 - отлом в результате обновлений - как раз и решает Snap? Вы не понимаете, что ваше стремление обновлять библиотеки независимо от собранного на них приложения как раз гарантированно и ведет к пункту 4?

Это порочная система. Надо обновлять библиотеки, пересобирать и тестировать приложение с обновленными библиотеками. Как это делается в Nix например. А не подсовывать приложению ломающие зависимости.

Итого - даже на сервере мы видим, что ваша deb пакетная система не состоятельна, а Snap даже тут решает проблемы. По десктопу вы вообще ничего привести не смогли, как я и ожидал.

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

Вы опять не поняли. Никакой убунты не будет. Ее выкинут вместе с порочными deb. Уже выкидывают, переводя приложения на Snap.

rpm собирались исключительно под тогдашний CentOS, но практически не использовались; deb собирались для Debian + кросс-компиляция для ARM (RPi), безо всяких проблем ставились и работали в тогдашней Ubuntu LTS.

То есть вы не сталкивались с задачей обеспечить работу приложения во всех, хотя бы основных используемых на момент сборки дистрибутивах. Причем нужно собирать еще и под разные версии одних и тех же дистрибутивов. Конечно вы не понимаете что с этим есть проблемы. Вы в курсе что у людей одновременно стоят убунты начиная с 16.x и до 20.x? А надо чтобы приложение везде работало.

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

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

Извините за такую аналогию, но если на вас напал третий рейх то придется подыхать сейчас. Чтобы следущее поколение жило.

В линуксе сейчас такая ситуация. Наше поколение должно пожертвовать собой во имя следующего. Иначе через некоторое время не будет ни нашего, ни следующего.

Большинство доступного открытого ПО присутствует в виде пакетов в основных дистрибутивах.

Нет, ничего не присутствует. Разуйте глаза.

Дедупликация работает, только если в пакетах содержатся абсолютно одинаковые файлы. В контексте библиотек - одной и той же версии и сборки. А поскольку почти каждый пакет snap тащит с собой недюжинное число таких библиотек, и это никак не регламентировано и не стандартизировано, то вероятность того, что в двух пакетах будет использоваться хотя бы одна и та же версия библиотеки (не говоря уже про сборку) весьма мала.

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

Вы не поверите, но проблема одновременной установки разных версий библиотек

Я что-то писал про проблему установки разных версий библиотек в том куске текcта, который вы цитируете? Как вы читаете? Тут речь идет про дедупликацию.

Очевидно что классические пакетные системы решают проблему дедупликации, они блин для этого были придуманы. Я писал про дедупликацию с самодостаточными пакетами, что намного сложнее.

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

По поводу дедупликации, возможен например такой вариант.

У нас репозиторий самодостаточных пакетов. В репозитории мы делаем «мегапакет». В нем - свалены все библиотеки, по максимуму. Создавать такой пакет можно по разному, даже при помощи apt из репов Debian, или как-то еще.

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

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

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

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

Если нужно, можно добавить любую свою стороннюю версию любой библиотеки. Но! Система сборки выдает варнинги - что вот вы нехорошо делаете. Имейте достаточно оснований для этого.

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

В веб-интерфейсе репозитория виден отчет по каждому самодостаточному пакету. Если в нем библиотеки не стандартные - выводится эта информация. Команда поддержки репозитория тогда должна пристально проверить такой пакет.

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

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

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

Да, запишите, желательно на лбу. Проблемы безопасности для десктопа ничтожны. Решая несуществующие проблемы, вы уничтожаете линукс на десктопе.

Всё с вами ясно. Рекомендую, когда будете пропагандировать повсеместный переход на snap, так и говорить: «При использовании snap ваши данные не будут в безопасности».

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

Примерно 10 лет назад эта модель себя полностью исчерпала. На настоящее время она не справляется вообще. Это катастрофа.

Попробуйте доказать, что именно модель себя исчерпала.

Но чтобы это понимать, надо использовать линукс на десктопе. Не на сервере. Не на картинках. Не для смены обоев или настройки тайлинга. Не для Vim в консоли. Для работы - на десктопе. Тогда все увидите.

Вот уже 15 лет использую исключительно GNU/Linux на десктопе, как для себя, так и на работе. Система управления пакетами решает все возложенные на неё обязанности. ЧЯДНТ?

Во-первых причем тут сервер. Мы говорим о линуксе на десктопе. Вы не понимаете, что на сервере совсем другие требования и задачи? Тогда осознайте для начала это. На десктопе работает не админ, а пользователь. Работает не с ограниченным набором серверного ПО, у которого и GUI то нет, а с большим набором десктопного ПО. Осознайте разницу. Я спрашивал не про сервер.

На сервере у нас какая-то совсем другая ОС используется, что ли? И если libpam или libc сломают на десктопе, это магическим образом не приведёт к проблемам?

Я привёл пример библиотек, общих для серверного и десктопного использования GNU/Linux.

Во-вторых - вы что, не понимаете что ваш пункт 4 - отлом в результате обновлений - как раз и решает Snap? Вы не понимаете, что ваше стремление обновлять библиотеки независимо от собранного на них приложения как раз гарантированно и ведет к пункту 4?

Эти библиотеки лежат в core, вообще-то. И речь как раз шла о сомнительной способности разработчиков Ubuntu качественно сопровождать общую для всех платформу. Вы совсем нить дискуссии потеряли?

Итого - даже на сервере мы видим, что ваша deb пакетная система не состоятельна, а Snap даже тут решает проблемы

Ну конечно! Ведь если те же libpam и libc сломать в core - это ну никак не приведёт к проблемам, ага.

По десктопу вы вообще ничего привести не смогли, как я и ожидал

Ну конечно! Ведь если те же самые библиотеки сломать на десктопе - это ну никак не приведёт к проблемам, ага №2.

Вы это, придержите коней - у меня фейспалмы заканчиваются!

То есть вы не сталкивались с задачей обеспечить работу приложения во всех, хотя бы основных используемых на момент сборки дистрибутивах. Причем нужно собирать еще и под разные версии одних и тех же дистрибутивов. Конечно вы не понимаете что с этим есть проблемы. Вы в курсе что у людей одновременно стоят убунты начиная с 16.x и до 20.x? А надо чтобы приложение везде работало.

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

При чём здесь работа программ, собранных в одном дистрибутиве, - в другом дистрибутиве? Опять, блин, напоминаю, что речь шла о сборке программы в каждом конкретном дистрибутиве представителями этих самых дистрибутивов. И говорилось это в контексте того, что для программ с открытым кодом, которые может собрать каждый, а не только их автор, модель распространения через исходный код с последующей сборкой для каждого дистрибутива уже силами самих дистрибутивов - полностью работоспособна.

В линуксе сейчас такая ситуация. Наше поколение должно пожертвовать собой во имя следующего. Иначе через некоторое время не будет ни нашего, ни следующего.

«Нужно сейчас потерпеть - зато наши дети будут жить при коммунизме!»

Нет, ничего не присутствует. Разуйте глаза.

Какие существенные открытые проекты, доступные для GNU/Linux, отсутствуют в виде собранных пакетов в основных дистрибутивах?

Я что-то писал про проблему установки разных версий библиотек в том куске текcта, который вы цитируете? Как вы читаете? Тут речь идет про дедупликацию.

Кусок текста, который я процитировал:

Эта проблема может быть решена технически, и ничего сверхъестественного в этом нет.

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

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

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

У вас нет ощущения, что возможности команды мейнтейнеров не безграничны? И что существующий ныне огород из библиотек, пакетов и прочих составных частей в большинстве дистрибутивов - результат именно этой ограниченности возможнностей? И чтобы худо-бедно причесать имеющееся по вашей схеме - нужны ресурсы как например в майкрософте?

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

Объединять приложения и библиотеки в огромный бандл - чтобы потом героически решать задачу разделения на составные части…

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

И если хоть где-то инфраструктура скомпрометирована, то сразу проблема у пользователей.

Ну если бы да кабы, то у башки б росли во рту грибы.

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

Не понимаешь сути самодостаточных пакетов.

А вот с универсальным пакетом неясно, какие там суммы, кто его будет подписывать?

Стор. Никакого рокетсаенса тут нет.

и обнаруживать и нейтрализовывать это будет сложнее.

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

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

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

Не понимаешь сути самодостаточных пакетов

Ну расскажи.

Стор. Никакого рокетсаенса тут нет.

Если стор будет подписывать всё, что в него заливают (разработчики), как эппл/гугл стор, то смысла в этом ноль.

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

Фаерфокс и обвешивает, кстати.
Нейтрализовывают другие. В некоторых дистрибутивах включен свой prefs.js, который отключает это. Есть tor browser на основе фаерфокса, и там тоже всё выпиливают. Для chromium есть форки, типа ungoogled.

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

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

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

bread
()
Ответ на: комментарий от curufinwe

Пеши исчо. Я потом саммари сделаю и буду веселить народ, который реально работает с реальным линуксом каждый день. Забавно, что твои фантазии частично реализованы сто лет назад в слаке. Там тоже есть «мегапакет» в виде полной установки, а сторонние пакеты как бы без зависимостей. Осталось сделать один шаг — самодостаточность. Вообще, можно всю убунту слить в один пакет, а мегакоманда мейнтейнеров пускай разгребает эту мегаслаку. Пакеты не нужны, юзеру кайф.

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

Ну расскажи.

Установка программ без зависимостей.

Фаерфокс и обвешивает, кстати.
Нейтрализовывают другие.
В некоторых дистрибутивах включен свой prefs.js, который отключает это.
Есть tor browser на основе фаерфокса, и там тоже всё выпиливают. > Для chromium есть форки, типа ungoogled.

И пакеты для винды как-то побудили закрыть их код?
Ещё раз говорю ты пишешь бред.

Репозитории с зависимостями и пересборка мейнтейнерами никак не влияют на опенсорсность и наличие трекеров.

Deb/Rpm пакеты никак не влияют на популярность открытых проектов, пользователей фаерфокса на винде тупо больше чем всех линуксоидов вместе взятых. Для них вообще винда это таргет платформа.

У тебя каша в голове о том как связаны опенсорс, линукс, дистрибутивы линукса, репозитории с зависимостями.

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

Используя линукс на своей машине ты не победишь мировое зло. Для победы над мировым злом тебе нужно мировое влияние, быть копорацией. Быть известным человеком как столман или линус не очень помогло (ядро хурд в упадке, линукс-десктоп стагнирует).

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

Установка программ без зависимостей

Какой в этом смысл, если пакеты будут лежать в репозитории дистрибутива? Ведь все зависимости лежат там же.

И пакеты для винды как-то побудили закрыть их код?

Чего? Не успеваю за твоим потоком

Репозитории с зависимостями и пересборка мейнтейнерами никак не влияют на опенсорсность

Да, прямо не влияют.
И собственно, я такое не утверждаю, но есть такое предположение, что поскольку софт сейчас распространяется в основном через репозитории дистрибутивов, а там мейнтейнеры собирают всё из исходников, то разрабатывая софт для линукса, разработчику приходится открывать код, если хочет чтобы софт был в дистрибутивном репозитории, и пользователи могли установить её тупым apt-get install и пользоваться.
А для винды достаточно freeware-экзешника, и всем в массе пофиг на исходники.

Используя линукс на своей машине ты не победишь мировое зло

У меня нет такой задачи.
Какая-то цель тут у опа, или с чего тут копротивляться за универсальные пакеты с проприетарщиной?

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

за универсальные пакеты с проприетарщиной?

Ты сам себе что-то придумал и с этим споришь. Поток здесь только у тебя.

Какой в этом смысл, если пакеты будут лежать в репозитории дистрибутива? Ведь все зависимости лежат там же.

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

разработчику приходится открывать код

Никому не приходится. Только по желанию. Если дистрибутив захочет, то внесут пакет в non-free, ну или растеряют пользователей которым non-free нужен для работы (чтобы деньги зарабатывать и кормить себя).

или с чего тут

Я тебе и так и эдак указывал. Тред перечитай, не знаю.

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

Отпадает необходимость в зависимостях

Ну и зачем, зависимости ставит пакетный менеджер. В чём удобство?

Сокращается фрагментация платформы

И что в этом хорошего?

Если дистрибутив захочет, то внесут пакет в non-free

Вносят что-то необходимое, типа драйвера nvidia. А плеер с нескучными обоями не внесут.
Когда-то на лор приносили новость про нескучный проприетарный плеер, который на винде жуют с причмокиванием, и тут разработчик его решил собрать под линукс.
Ну чё, обоссали, даже новость в итоге выпилили, только в вебархиве осталось
https://web.archive.org/web/20191020221938/https://www.linux.org.ru/news/mult...

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

И что в этом хорошего?

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

«А ну я снова тот же вопрос задам, и всё по круго, а в этом что хорошего, а я в сказки верю, подождём ещё 20 лет, ну и что, в чём удобство».

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

«Ну тупой ну и что, а что в этом плохого, а ты сам наверное тупой. Гыгыг мы же знаем что винда плахая, а линукс святой».

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

В цифровом гулаге нельзя две версии, нельзя откатывать, нельзя обновляться раньше мейнтейнера.

ВСЁ РАДИ ВАШЕЙ БЕЗОПАСНОСТИ
Общество которое выбирает безопасность, теряет и свободу и безопасность.

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

Не буду листать 7 страниц, но если ты за «айн линукс, айн редхат, ...», то дурак здесь ты. Такой линукс и правда ненужон

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

В gentoo например есть слоты, но вообще это проблема пакетных дистрибутивов, да.

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

При том что на винде двадцать лет пытаются разгребать эти авгиевы конюшни, придумывая всякие chocolatey и win-get, и совсем недавно даже что-то получается.

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

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

Такой линукс и правда ненужон

ХА-ХА-ХА, куда ты денешься. На ненавистную винду убежишь?

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

scoop кстати неплохой.
Чоко для домашнего использования не подходит, имхо.
Homebrew на маке это просто сказка, лучшее из всех миров.

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

«При использовании snap ваши данные не будут в безопасности».

Вы тут правы. Я теперь всегда буду говорить - при использовании любых систем на основе Linux на декстопе у вас нет никакой безопасности. Нет никакой сохранности данных. Никогда. Если у вас deb, rpm, tar.gz - вы уже под ударом. Годами. Но - когда вам предложат вылезти с помойки, и хоть как-то привнести безопасность во все это, старожилы с засохшим мозгом будут втирать вам дебильный миф что какая-то безопасность есть. Потому что они вообще ничего не понимают, не понимают устройства линукса, не понимают источников угроз в обычном классическом линуксе на десктопе. Просто повторяют чушь за каким-то идиотом, который первым это придумал.

Попробуйте доказать, что именно модель себя исчерпала.

Можно доказать, но тогда когда собеседник перестанет быть аналогом бетонной стены.

Вот уже 15 лет использую исключительно GNU/Linux на десктопе, как для себя, так и на работе. Система управления пакетами решает все возложенные на неё обязанности. ЧЯДНТ?

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

На сервере у нас какая-то совсем другая ОС используется, что ли?

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

И если libpam или libc сломают на десктопе, это магическим образом не приведёт к проблемам?

На десктопе ничего не сломают, потому что вашу дурацкую пакетую систему где все ломают скоро выкинут на мороз. И если это сделает не Snap и не Flatpak, то уж точно NixOS. По сравнению с ним ваш deb тупое убожество.

При чём здесь работа программ, собранных в одном дистрибутиве, - в другом дистрибутиве?

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

которые может собрать каждый

Не может. Ничего вы не соберете. И я не соберу. И никто.

Ведь если те же самые библиотеки сломать на десктопе

С таким подходом можно и хрен сломать. Если так сильно хотеть.

«Нужно сейчас потерпеть - зато наши дети будут жить при коммунизме!»

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

Какие существенные открытые проекты, доступные для GNU/Linux, отсутствуют в виде собранных пакетов в основных дистрибутивах?

OpenModelica. Elmer. Robot Operating System. Salome-Meca. И черте чего еще.

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

Вы ничего не поняли. Ваше решение на практике бесполезно. Пакет должен быть самодостаточным. Именно по причине бесполезности ваш вариант решения никем не рассматривается, а созданы Snap, Flatpak, Nix.

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

каша в голове о том как связаны опенсорс, линукс, дистрибутивы линукса, репозитории с зависимостями.

Верно, особо никак не связаны. Опенсорс это идеология не связанная с конкретными осями. Линукс как ядро живет своей жизнью, в том числе вне опенсорса. ОСлинукс про который этот форум, это опенсорс + репозитории с зависимостями. В такой ОС кстати может не быть ядра линукс совсем. Вы с эльфом фантазируете о винде с ядром линукс. Так что каждый о своем талдычит. Наиболее идеологически и технически близок вам макос, о чем я постоянно напоминаю. Ну и сфигали им не пользоваться?

bread
()
Ответ на: комментарий от Rootlexx

Объединять приложения и библиотеки в огромный бандл - чтобы потом героически решать задачу разделения на составные части…

Это показательно - вы не способны понимать написанное. Вы ничего не поняли, вообще. Никакие приложения я в огромный бандл не предлагаю объединять, вы что ошизели? Ничего разрезать я тем более не предлагал ни на какие части. Господи… Как можно смотреть в книгу и видеть фигу… О чем с вами говорить?

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

Если ты серьёзно это пишешь, то ты правда просто тупой.
Ты это серьёзно — если да, то я постараюсь игнорировать тебя.

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

Ты там линукс уже ставишь, или так потрендеть пришел, пользователь ведроида? Кому твое мнение ребенка с планшетиком вообще тут интересно?

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

А правда, чем тебе винда не угодила? На опенсорс тебе пофиг, про зонды и безопасность - ненужно и для неуловимых джо.
Чем тебя не устроили винда и макось?

Ну и да, кнопка - в профиле

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

У вас нет ощущения, что возможности команды мейнтейнеров не безграничны?

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

Почему мейнтейнеры дебиана справляются? Мейнтейнеры флатпака как рантайм умудряются делать?

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

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

На опенсорс тебе пофиг

Ложь. Опять сам себе придумал сказку и всё смешал в кучу. Уже пояснял по этому поводу.

безопасность - ненужно и для неуловимых джо

Перевирание. Ты даже сам не замечаешь как всё в кучу сваливаешь.

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

Выше писал про всё остальное.

Что за кнопка в профиле?

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

А решать вот эти названные 8 пунктов надо?

Тихо шифером шурша, крыша едет не спеша (у Linux Mint) (комментарий)

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

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

Продолжай натягивать сову на глобус, я не буду мешать.

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

Да, перепаковкой не сделать. Перепаковка - это для экспериментальной демонстрации и отработки начальных версий утилит.

А вообще такой репозиторий конечно не должен «воровать» перепаковкой, надо чтобы была команда которая все это будет делать. Но ведь это по трудозатратам аналогично репозиторию других, существующих дистрибутивов. Вот тот же Nix, там и все библиотеки, и разные версии одних и тех же библиотек, все это поддерживается его командой. Ничего сверхъестественного тут нет.

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

Но ведь это по трудозатратам аналогично репозиторию других, существующих дистрибутивов.

Навряд ли. Любой другой дистр имеет примерно те же 8 перечисленных вами недостатков. Это неотъемлемая черта всего GNU зоопарка, собираемого с миру по нитке. Чтобы обеспечить мало мальски цельность, слитность, струкутурированность - этим должна заниматься административная структура с деньгами и полномочиями. А без этого все мейнтейнеры обречены на непрерывное разгребание зависимостей и у них просто нет никакой возможности вот так раз и навсегда выделить базу, приложения, библиотеки и следить чтобы и все другие делали то же самое. А если остальные не будут делать то же самое - их опять быстро завалит неструктурированным потоком.

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

Любой другой дистр имеет примерно те же 8 перечисленных вами недостатков.

Ну как же. Flathub, Snap Store, NixOS не имеют. Они имеют другие, но эти - нет. Есть группы людей, которые это сделали. Это не прожекты, вот они - пожалуйста, они существуют. Никакой Microsoft для их создания не понадобился. Хватило тех структур что уже есть в мире линукса.

этим должна заниматься административная структура с деньгами и полномочиями

У нас есть как минимум две такие структуры - Canonical и Red Hat. Тут проблема скорее что их больше одной, а не в том что их нет.

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

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

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

Короче, нужен один новый Линус с кучей денег, соответствующей властью и кучей подчиненных, и чтобы его слово было законом для всех дистросоставителей и гнуписателей ) Правда ему еще нужно будет объяснить что вы от него хотите )

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

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

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

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

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

Хорошо но крайне маловероятно ) Можно даже сказать - утопия ) Я бы поставил 10 против 1 на то, что линукс вообще останется примерно в том же состоянии, как сейчас, с постепенной деградацией из-за того, что обсуждалось тут с месяц назад - отщипыванием от него кусков для коммерческих применений и ростом всякой проприетарщины - как в железе, так и в софте.

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

Вы тут правы. Я теперь всегда буду говорить - при использовании любых систем на основе Linux на декстопе у вас нет никакой безопасности. Нет никакой сохранности данных. Никогда. Если у вас deb, rpm, tar.gz - вы уже под ударом. Годами. Но - когда вам предложат вылезти с помойки, и хоть как-то привнести безопасность во все это, старожилы с засохшим мозгом будут втирать вам дебильный миф что какая-то безопасность есть. Потому что они вообще ничего не понимают, не понимают устройства линукса, не понимают источников угроз в обычном классическом линуксе на десктопе. Просто повторяют чушь за каким-то идиотом, который первым это придумал.

Уровень демагогии зашкалил. Уровень аргументации, как обычно, на нуле.

Хотя что это я… Ведь в Windows были всякие там WannaCry, и эта ОС занимает 90+ процентов рынка… «Этого достаточно чтобы как минимум задуматься.» ©

Можно доказать, но тогда когда собеседник перестанет быть аналогом бетонной стены.

«Могу доказать, конечно могу - просто не хочу, да ты и не поймёшь.»

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

Ну конечно - все, кто с вами не согласен, просто дурачки: живут себе на помойке и не видят светлого будущего, которое когда-нибудь обязательно, точно, «мамой клянусь!» - наступит. И вовсе не потому, что ваши аргументы считают недостаточно убедительными и высказывают свои - а просто глупенькие они.

Я верно передал вашу мысль?

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

И вы ещё хотите, чтобы вас воспринимали серьёзно…

Хоть GUI, хоть не GUI - приложения используют библиотеки. И представьте себе - многие библиотеки используются как серверными приложениями, так и десктопными! А значит, если сломать эти библиотеки, то сломаются как серверные приложения, так и десктопные! - представляете? И в таком случае неважно, что на проблему с какой-нибудь libpam напоролись, используя Ubuntu Server, - точно так же возникли бы проблемы и с любым десктопным приложением/сервисом, использующим данную библиотеку.

Видимо, это очень сложно для вашего понимания, раз такой тривиальный факт приходится объяснять на пальцах.

На десктопе ничего не сломают, потому что вашу дурацкую пакетую систему где все ломают скоро выкинут на мороз.

Ну конечно - если ту же библиотеку сломают в core snap или в flatpak runtime, то это в корне поменяет дело!

И если это сделает не Snap и не Flatpak, то уж точно NixOS.

Кто ещё там в кандидатах на серебряную пулю?

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

Программа будет работать в каждом дистрибутиве, для которого её соберут. Пакет же в общем случае не обязан работать во всех дистрибутивах. Если же это необходимо (например, ввиду закрытых исходных кодов), вот тогда для этих частных случаев пускай будет flatpack/snap/appimage/что-то ещё.

Не может. Ничего вы не соберете. И я не соберу. И никто.

Это уже какие-то бредни пошли…

С таким подходом можно и хрен сломать. Если так сильно хотеть.

Ну что поделать, если разработчики Ubuntu неоднократно умудрились.

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

Я вижу, у вас фиксация на «бояре». Сочувствую вам в вашей беде.

OpenModelica. Elmer. Robot Operating System. Salome-Meca. И черте чего еще.

Это ну никак не большинство, а весьма специфические проекты.

При этом для того же Debian они прекрасно собирают сами. Не в курсе, наверное, что это так сложно.

В Arch есть в AUR.

OpenModelica

https://build.openmodelica.org/apt/dists/buster/

https://aur.archlinux.org/packages/?O=0&K=openmodelica

https://build.openmodelica.org/rpm/

Elmer

https://aur.archlinux.org/packages/?O=0&SeB=nd&K=elmer&outdated=&SB=n&SO=a&PP=50&do_Search=Go

https://www.csc.fi/web/elmer/binaries:

There is a Linux version at launchpad that can be used on Ubuntu and Debian based systems:

Robot Operating System

http://wiki.ros.org/noetic/Installation/Debian

https://aur.archlinux.org/packages/?O=0&SeB=nd&K=ros-&outdated=&SB=n&SO=a&PP=50&do_Search=Go

https://rpmfind.net/linux/rpm2html/search.php?query=ros-&submit=Search+...&system=&arch=

И при этом: https://ibb.co/HFsMYLT. Печалька. 🙂

Вы ничего не поняли. Ваше решение на практике бесполезно. Пакет должен быть самодостаточным

Какое изобилие аргументов!

snap/flatpak претендуют на решение двух проблем:

  1. Возможное отсутствие библиотеки нужной версии в репозитории.

  2. Кроссдистрибутивность.

Первую проблему возможность одновременной установки нескольких версий библиотеки решить позволяет.

Вторая проблема по определению актуальна лишь для сборок программ, не входящих в дистрибутив, о чём я и говорю.

Это показательно - вы не способны понимать написанное. Вы ничего не поняли, вообще. Никакие приложения я в огромный бандл не предлагаю объединять, вы что ошизели?

Внезапно, «самодостаточные пакеты» - это и есть огромный бандл, объединяющий приложения и библиотеки.

Ничего разрезать я тем более не предлагал ни на какие части.

Во-первых, я написал «разделять», а не «разрезать». Т.е. выделять отдельные составные части, не создавая из них отдельную сущность.

Далее, ваши слова:

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

«Можно еще больше оптимизировать - само скачивание, сделать скачивание дельтами, чтобы одинаковые файлы и через сеть не гонялись

Т.е. предлагаете иметь дело не с единой логической сущностью - пакетом, а уже с отдельными входящими в него файлами. Что и является разделением пакета.

Господи… Как можно смотреть в книгу и видеть фигу… О чем с вами говорить?

https://chinaparcel.ru/wp-content/uploads/2018/01/aliexpress-returned-to-sender.jpg

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

Нас рассудит время.

Но если я даже проиграю - я хотя бы пытался. Мне не будет мучительно больно за бесцельно прожитые годы. Даже если линукс сгниет. А вот вам… Это вам решать.

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