Comments 109
Менеджеры пакетов с зависимостями - одна из худших инженерных идей в истории ойти, гдето на одном уровне с electron.
Вместо того чтобы решать проблемы и упрощать жизнь - эта идея порождает проблемы. Ярчайшие примеры - dependency hell в линуксе, пакеты в npm с 500 вложенным и зависимостями и т.п.
Какое решение распространения кода вы предложите?
Менеджеры пакетов без зависимостей. Apk \ F-Droid идеальный пример.
Какое решение распространения кода вы предложите?
+1 Я бы даже сформулировал как "какое более эффективное решение для повторного использования бинарного кода предложите?"
Акцент в вашем вопросе на слове "повторного" совершенно не верен с моей точки зрения
А с точки зрения пакетного менеджера — это то, для чего он создан и чем занимается.
Вот в чем фикус-то.
Кстати, с менеджером без зависимостей, упомянутым тредстартером, есть такой забавный нюанс: вот зависит приложение от system webwiew — но где там, оно будет установлено даже в его отсутствие, не говоря уже про вшитые и заброшенные версии от вендора. Просто падать будет, если разработчик не предусмотрел костыль.
И в рамках дихотомии костыли в каждом проекте vs централизованная проверка зависимостей: и как пользователь, и как писатель, и как администратор — этот предпочтет нормальный пакетный менеджер, который сразу скажет что так оно работать не будет, инфантильному инсталлятору без проверок.
Кажется, в том комментарии предложили менеджер без зависимостей в виде flatpak/snap. Когда всё нужное ставится каждый раз заново одним пакетом.
Перечитал ветку выше — но там только в корневом комментарии предлагается Apk \ F-Droid идеальный пример.
На котором очень уж удобно продемонстрировать ошибку)
Даже если закрыть глаза на проблемы с безопасностью при таком подходе, распухание для krita или браузера на сотню мегабайт — не слишком критично, они и так весят немало.
Распухание на сотню мегабайт каждого бинаря из /bin — это конец.
Ну и всегда остаются слабые зависимости: графическая среда и ее утилиты, видеокодек, сеть и прочая и прочая.
+1 Я бы даже сформулировал как "какое более эффективное решение для повторного использования бинарного кода предложите?"
Я бы сформулировал вопрос вообще по-другому: Как называется болезнь, когда человек создает реальные проблемы программистам (распространение и поддержка софта) и юзерам (установка софта), чтобы решить воображаемую (повторное использования бинарного кода)?
Как гентушник, в эпоху интернета и git, для меня дикость доверять бинарному Г..
Охлол, ну доверяй тогда опенсурсу из npm, где сегодня сбилженая аппа с миллионом вложенных зависимостей решает свою задачу, а та же самая аппа, сбилженая через неделю ворует пароли. Потому что у половины пакетов даже версии нефиксированные, и гдето там в глубоких слоях зависимостей ктото закоммитил плохое зло, а отревьюить миллион пакетов нереально.
Ты можешь доверять софту только потому, что он написан на няшкой сишечке или плюсах, у которых нету пакетных менеджеров и либы берутся либо из сорцами папки third-party, либо из системы. И поэтому разрабу пришлось думать, а не пакет с пакетами из помойки тащить. С npm, pipом и прочими порождениями сверхразумов доверять исходникам у тебя уже не получится.
да нет никаких проблем, на машине с инетом
Пакетный менеджер - придуман чтобы экономить память. Но никаких проблем нет - просто скачай половину репы. Это просто шиза, создать кучу гемороя, чтобы потом всрать основной поинт этой геморной системы. А юзер всеравно в итоге поставит флетпак, скачает гиг мусора чтобы запустить калькулятор, просто потому что так оно хотябы работает без боли.
если ты пытаешься ставить пакет с ubuntu на debian то ССЗБ
Это тоже следствие того что зависимости в пакетах - одной из худших решений ever. Пакеты между двумя deb дистрбутивами даже не совместимы, это лол. Т.е. мейнтейнеры буквально допиливают софт под набор костылей, называемый дистрибутивом, иначе оно вообще нежизнеспособно.
Кстати, с менеджером без зависимостей, упомянутым тредстартером, есть такой забавный нюанс
Ну есть и есть, у тебя все аргмуенты построены на "хитрой" схеме. Я говорю - пакетные менеджеры с зависимостями создают dependency hell и это создает вагон проблем, как разрабам, так и юзерам, буквально by design. Ты в ответ выискиваешь в других подходах какието маргинальные кейсы, типа на винде иногда dllки дебил-автор забудет с прогой положить, или на ведре системный webview кривожопый. И приравниваешь эти проблемы.
Типа по-твоему системная проблема, которая генерит геморой на ровном месте регулярно и фиксится только отказом от такого подхода - это тоже самое, что решение в котором проблемы возникают в 1-2% случаев и не требуют переделки всей системы для фикса.
так оно работать не будет
Вот именно поэтому пакетные менеджеры прижились только на 1% ос и у полоумных джиесеров в npmе. Юзеру надо что аппа ставилась и работала, а с пакетным менеджером оно регулярно работать не будет. Да, да, я знаю у тебя такой же линукс и все работает. Вон у джавистов например джава не тормозит, это же не стало правдой.
Добавишь в установщик apk зависимости, разрабы начнут туда говнолибы и прочие свои поделки пихать - и проблемы, подобные косякам с системным WebView будут возникать постоянно.
На ведро уже пытались протащить заивисисмости, когда туда портировали Qt. В итоге эта идея быстро загнулась, юзеры не поняли почему они должны гемором заниматься, вместо того чтобы apk поставить.
Винда тоже смотрится не очень
В Винде легко какая-нибудь сборка может упереться в какую-нибудь исполняемую среду визуалстудии
Смотрится не очень, зато работает без боли. Установить иногда vsredist, да даже 10 версий этого vsredist разом куда меньший геморой, чем разруливать зависимости в линуксе.
все аргмуенты построены на "хитрой" схеме
Особенно хитрой становится схема, когда начинаешь учить матчасть и — ВНЕЗАПНО! — понимаешь, что начиная с 7 в винде реализовано то же самое: версии, зависимости и вот это вот все, только с мелкомягкой спецификой )
У вас какие-нибудь пригодные к обсуждению аргументы-то найдутся, кроме бессмысленного и беспощадного вайна?
Пакетный менеджер - придуман чтобы экономить память.
пакетный менеджер рассчитан на наличие интернета, внезапно. А то ты сначала выдумываешь ситуации, а виноват в итоге пакетный менеджер )))
Это тоже следствие того что зависимости в пакетах - одной из худших решений ever.
никаких проблем не вижу. Зависимости избавляют от кучи проблем с софтом
Пакеты между двумя deb дистрбутивами даже не совместимы, это лол.
а с чего они должны быть совместимы лол ? Поставь поршни от бмв на ауди, внезапно они не совместимы :D
Т.е. мейнтейнеры буквально допиливают софт под набор костылей называемый дистрибутивом, иначе оно вообще нежизнеспособно.
никто ничего не допиливает, а выбирают по их мнению самые стабильные версии. Не нравится - Welcome to Linux From Scratch!
Юзеры ой разные бывают.
У меня вполне были случаи когда надо было пересобрать (и собирать новый) весь софт установленный менеджером на машине конкретной версией комплилятора с конкретными ключами. Ах да, тот софт что поддерживает интеграцию с KDE — с версией KDE которая официально выйдет через несколько дней.
Весь это именно весь, включая сам компилятор, binutils и прочее.
И да, это вполне себе имело смысл с точки зрения производительности (и речь не про 0.02% и не 2% если что)
Gentoo вполне себе позволяет такое. При этом для тех кто готов доверить сборку кому то еще — тоже есть опция.
Ну вот flatpak есть... Буквально на днях: vlc, установленный пакетным менеджером, дико глючит. Vlc, установленный из flatpak, работает нормально.
Но тянет он с собой много, да.
Как гентушник, в эпоху интернета и git, для меня дикость доверять бинарному Г.. и не оптимизированному под мое железо (march=native) . Зависимости при установке из исходников - наименьшая из проблем
бинарному Г.. и не оптимизированному под мое железо
Можете привести какой-нить довод зачем мне нужно оптимизировать под свое железо почтовый клиент. Почта быстрее ходить станет?
на 0.02% ?
10 раз от какого времени? я разницу между микросекундами и милисекундами не замечу.
Смотря где и как — я вот бы очень непротив чтобы поиск в Calibre (обычны фильтр который а не тот что FTS из Calibre6, FTS это не замена) работал в 10 раз быстрее пусть даже ценой пожирания в 10 раз больше ядер на этот поиск (вот чего у меня хватает на текущей машине — так это ядер) или жором памяти в 10 раз больше.
Потому что дико раздражает.
Да, видимо проявляется то, что этот юзкейс там вообще не думали оптимизировать.
Для интереса качнул такой же греп, что у меня в убунте (3.7), собрал его через make CFLAGS="-O2 -pipe -march=native -floop-interchange -floop-strip-mine -floop-block"
И запустил по 100 тестов а-ля "grep -ri pogchamp" по ~/ для собранного и системного - системный греп отрабатывает в среднем на пару-тройку процентов быстрее.
Что я делаю не так? В линуксокопошении не силен.
i7-13700KF, DDR5-6400, Kingston KC3000 2tb ссд.
Так давайте проведем бенчмарк и сделаем понятные выводы?
Идея грепа в том - что это как раз тот самый полнотекстовый поиск, пакет из репо убунты для всех, и те же сырцы, перекомпилированные ПОД СЕБЯ, ровно так, как вы написали в комменте ниже.
На 100 запусках каждого бенча есть повторяемая разница в пару-тройку процентов в пользу пакета из репо.
Я просто очень хочу обещанное х10 ускорение увидеть. В идеале, без читерства а-ля #ifdef AVX512_SUPPORTED
В эпоху IMAP, когда поиск писем практически всегда выполняется сервером?
или поиск всех писем, содержащих близкие в word2vec слова к «досада» [...] В качестве задачи со звёздочкой помогите это сделать через IMAP, если письма зашифрованы каким-нибудь там GPG
Это конечно же делается в стандартном почтовом клиенте, который нужно просто пересобрать с нужными флагами, а не с помощью чего-то самописного. И конечно тут главный вклад внесет время самого поиска, а не скачивания pdf-ок, и не чтение их с диска.
Ну и главное тут — чтобы треды с нытьём о тормозах современного ПО и треды «гагага зачем собирать ПО под свою машину с sse 4.2/avx2/avx512 оптимизаторы хреновы))))» были достаточно разнесены в пространстве-времени, а то иначе вопросы могут возникнуть даже у авторов таких комментариев.
Современное ПО если тормозит, то явно не от того, что собрано без поддержки AVX512 инструкций, и то что оживить старый комп на 10-летней давности Core i5 помогает вовсе не замена проца и пересборка ПО, а замена диска на SSD очень жирно на это намекает. Есть исключения, в виде задач обработки изображений, рендера видео или рассчетов в CADах, но это явное меньшинство.
Как дела с фильтрацией по теме или отправителю?
Сложно сказать без тестов, и уж это то точно без проблем делается на стороне сервера.
С word2vec да, я сам себе свои костыли написал. Но на вопрос о том, «зачем», это, надеюсь, отвечает?
В контексте обсуждения пакетных менеджеров, обсуждать то, насколько ускорились свои самописные костыли просто не имеет смысла, имеет смысл обсуждать какой прирост даст пересборка популярных пакетов. Впрочем, надо будет просто как нибудь взять, да погонять под Дженту и под Убунтой какие-нибудь популярные вещи типа Chromium/Firefox, парочку СУБД, да какой-нибудь PHP и сравнить.
Качаете их вы в любом случае и один раз.
Если я не ищу в них потом текст постоянно, то время на сам поиск в любом случае будет мало в сравнении со временем скачивания. То же самое относится и к индексам -- если я не ищу по письмам постоянно, то время на скачивание и индексирование будет многократно превышать время на сам поиск, и даже ускорение его в десять раз не будет играть роли в скорости получения итогового результата, потому что бутылочное горлышко в данном случае совсем в другом месте. В народе это называется "экономией на спичках".
Каждый раз, читая такие вот «перепалки» в комментариях, поражаюсь, насколько, оказывается, люди бережно относятся к своему времени.
Традиционный пример: слепая печать. Сама по себе — она очень полезна: смотреть в экран гораздо удобнее, чем на клавиатуру, опечатки сразу заметны, вычитка фактически не требуется. Но скорость? Я, например, не машинистка, я сука господин инженер, у меня основные временны́е затраты связаны с тем, что я гуляю по окрестностям и думаю. Увеличение скорости печати даже в триста раз — даст выигрыш в один процент от общего времени, потраченного на задачу.
Поиск писем. Выигрыш в пусть 500%. Минута вместо пяти. Ну так я запущу поиск и пойду выкурю сигарету, разомну ноги, почитаю порнхаб в соседней вкладке.
Кроме того, сейчас даже 256G оперативки — не бог весть какие деньги, по-моему проще инвестировать в мощность компьютера, чем во флаги компилятора, если уж так привспичилось.
Возможно, такое мое спокойное отношение к чуть более медленному выполнению обусловлено фантомными болями от компиляции плюсовых проектиков на DX486/2M и скачиванием картинок из вновь созданной международной сети интернет на рвущемся модемном (9600) соединении.
Одно дело сравнительно редкая операция, которая занимает минуту, пять или десять — тут действительно не проблема отвлечься на что-то ещё, и совсем другое — частая, которая выполняется в пределах нескольких секунд — в таком случае лишние задержки сбивают с мысли и раздражают. В программировании характерные примеры последних — задержка ввода и статический анализ.
Да?
Ну вот недавний пример мой.
Ryzen 5 1600.
Виртуалка на Proxmox(если что — флаги поддержки AVX виртуалке передаются принудительно) а в ней Peertube.
транскодинг видео.
скорость хорошо если x0.1
возможности пробросить видеокарту и кодировать видеокартой — нет.
Решить проблему нормально… помог выход Peertube 5.1 с поддержкой remote transcoding и запуск runner'а на более слабой машине с более старым cpu но от Intel.
Похоже что-то не так с поддержкой amd у ffmpeg (+возможно как то влияет именно запуск из виртуалки, вот только тесты в контейнере тоже показали не самые обнадеживающие результаты — ffmpeg и там тормозит)
Скажите это Proton Mail :)
Где поиск через web-интерфейс работает… по локальному кешу.
А потому что безопасности и на сервере все зашифровано.
Ну так, просто для сведения: синтетические тесты на PHP, поставленном из бинарника отрабатывают примерно на 20-25% дольше, чем те же самые тесты, но выполненные на PHP скомпилированном под конкретную архитектуру.
Несколько лет назад на генте проверял.
Сейчас бы проверил с пайтоном и pytorch, но у меня уже нет генты..
Как гентушник, в эпоху интернета и git, для меня дикость доверять бинарному Г.. и не оптимизированному под мое железо (march=native). Зависимости при установке из исходников - наименьшая из проблем
а вот и оптимизаторы с секретными ключами сборок подъехали. Только они знают секретные ключи сборки, которые позволят собрать пакет и он будет работать на 0,00001% быстрее, но это не точно. Причем, как правило, это оптимизаторы потом ни за что не отвечают и в случае чего, всю вину валят на ментейнеров.
В k8s тоже предлагаете компилить все из исходников в инит контейнерах, нее ну а чо, удобно же
Что секретного в
-O2 -pipe -march=native -floop-interchange -floop-strip-mine -floop-block
и что оно дает по сравнению со стандартными ключами дистрибутива ?
Не пользуюсь k8s и даже не знаю, зачем он мне был бы нужен.
не пользуешься, это не значит что он не нужен другим
Что вам там даёт k8s, 0.02% удобства?
а с чем сравниваем ? Если с vps/vds - то 1000%. Если взять аналогию - сравните ваз и мерседес
Вы знакомы с
-march?
в общих чертах.
Я имел ввиду, вот мы перекомпилировали все утилиты из coreutils c этими ключами, что мы как devops/сисадмин от этого выиграли ? У нас база данных стала быстрее запросы выполнять или rps в nginx вырос в 2-3 раза.
Ответ очевиден - конечно же нет. Тогда напрашивается вопрос - мы это делали чтобы что ? А теперь умножаем количество серверов на 1000. Все еще хочется пересобирать пакеты ? А обновления уязвимости выходят раз в неделю и поехали перекомпилировать на 1000 серверов
P.S.
я не рассматриваю случай, когда мы это делаем на личном ноуте. Там как говорится - играйся на здоровье, если есть время и желание
Бенчмарки покажете? :]
бенчмарки удобства ? ))) Ну самое банальное, вам через 5 минут надо поднять 100/200/300/1000 нод на arm и запустить тест.
Но я не девопс и не сисадмин. Дома — вы сами написали, всем пофиг. На работе — я как раз пишу (вернее, раньше писал) эти самые числодробилки, и там всё собирается под конкретное железо.
ну так это эдж кейс. Конечно для таких случаев оно имеет смысл и место быть. Более того, там и до asm вставок можно скатиться и оно будет иметь смысл
Что вам там даёт k8s, 0.02% удобства?
Предсказуемость работы на различных этапах, автоскейлинг, автоматическая балансировка нагрузки и автоматический перезапуск упавших частей системы, это куда больше чем "0.02% удобства".
Это проходит. Я этим 15 лет назад тоже болел.
В начале 2к кеды + либра опенофис собиралось из исходников 2 дня. Зато оптимизировано под мое железо...
Менеджеры пакетов с зависимостями - одна из худших инженерных идей в истории ойти
Мне тоже накипело. Пакетные менеджеры - сложная вещь, при желании их легко можно ввести в ступор. Если бы я коллекционировал все ошибки, которые выдает пакетный менеджер, накопилось бы на целую тетрадку.
Сейчас я уже освоился с ним, но крови он попил прилично в свое время.
Порой приходится вручную лезть в пакеты, стирать ненужные зависимости, ведь программа работает и без них.
Ни один пакетный менеджер еще не научился подгружать библиотеки для бинарника в runtime. Это все по прежнему вручную происходит. И это бесит. Особенно если нужный файлик находится в пакете с совсем другим именем, ничего не напоминающем. В разных дистрах имена одного и того же пакета разные, естественно.
Если для бинарника нужна библиотека другой версии, то без шансов. Не запустишь. Я так и не смог запустить нужную программу для звукорежиссеров, просто потому что там gtk старый.
Установка программ на машину без интернета - отдельная очень длинная и сложная история, даже не буду трогать. Винда здесь выигрывает однозначно.
Винда тоже смотрится не очень особенно в директории winsxs. Да и навязчивые добавления искусственной не совместимости со старыми версиями тоже.
В Винде легко какая-нибудь сборка может упереться в какую-нибудь исполняемую среду визуалстудии.
После чего говорит: - прощайте.
Установка программ на машину без интернета - отдельная очень длинная и сложная история, даже не буду трогать.
да нет никаких проблем, на машине с инетом
$ yum install --downloadonly --downloaddir=/mnt/downloads git mc wget curl unzip gitна машине без инета просто
$ yum install /mnt/downloads/*Винда здесь выигрывает однозначно.
ну да ну да
Порой приходится вручную лезть в пакеты, стирать ненужные зависимости, ведь программа работает и без них.
зачем ? Чтобы сэкономить 1 мб дискового места ? Если зависимость реально не нужна, то делаешь PR мейнтейнеру и ее удаляют
Это все по прежнему вручную происходит. И это бесит. Особенно если нужный файлик находится в пакете с совсем другим именем, ничего не напоминающем.
yum install git ничего в ручную не ставлю
В разных дистрах имена одного и того же пакета разные, естественно.
если ты пытаешься ставить пакет с ubuntu на debian то ССЗБ
Ни один пакетный менеджер еще не научился подгружать библиотеки для бинарника в runtime.
Выше пример что Apk считается пакетным менеджером. Если мы иметь ввиду Google Play а конкертные библиотеки задействуються конкретными компонентами приложения то… уже
из описания Dynamic Delivery с https://habr.com/ru/companies/badoo/articles/489434/
Функции под А/B-тестами и пользовательскими группами. Некоторые функции могут быть доступны только в определённых регионах, и без Dynamic Delivery они лежат мёртвым грузом в устройствах всех остальных пользователей.
Специфичные функции, которые нужны не всем пользователям. Классический пример — модуль с камерой и распознаванием номера банковской карты.
Функции, которые перестают быть доступны после каких-то действий пользователя. Например, это могут быть экраны регистрации, которые можно удалить после регистрации и установить заново, если пользователь решит зарегистрировать другой аккаунт.
На самом деле, менеджеры с зависимостями очень эффективно решают ряд проблем:
- экономия постоянной памяти
- экономия оперативной памяти
- оперативное исправление уязвимостей и прочих ошибок в зависимостях.
При этом они не вносят никаких новых проблем до тех пор, пока используются для популярного, активно развивающегося, открытого софта. А вот если по этим параметрам достаточно далеко уходить (особенно по нескольким сразу), то начинаются проблемы, и в какой-то момент действительно становится проще воспользоваться flatpak/snap/AppImage.
Но благо никто не заставляет выбирать что-то одно, последние никак не конфликтуют с первыми, и ничего не мешает использовать для части софта условный pacman, а для другой условный flatpak.
На самом деле, менеджеры с зависимостями очень эффективно решают ряд проблем:
Это я и называю выпиюще дерьмовым инженерным решением.
Потому что первые 2 проблемы вообще не существуют. А любые бенефиты от экономии на спичках аннулируются как только юзер ставит flatpak.
А третья решается лишь теоретически, при условии что весь софт установлен через менеджер пакетов, а не через flatpak/snap/AppImage или бинарь без зависимостей, что зависимости системные а не вкомпилены в исходники, что мейнтейнеры не прокекают момент, и что репа не помойка типа aur или npm и т.п. Т.е. в условиях, не существующих в реальной жизни.
При этом они не вносят никаких новых проблем до тех пор, пока используются для популярного, активно развивающегося, открытого софта
Т.е. пока юзер пользуется только софтом, специально допиленным мейнтейнером под дистрибутив. Этот подход с репой и мейнтейнерами под каждый дистр вообще не масштабируемый. Миллон разрабов может мейнтейнить по одной аппе, в итоге мейнтейня миллон апп. Миллион апп в каждой репе под каждый дистр отдельно, силой нескольких мейнтейнеров это уже unmaintainable.
ничего не мешает использовать для части софта условный pacman, а для другой условный flatpak.
В итоге и профитов никаких нет, а проблемы собрали со всех мест.
пакетный менеджер рассчитан на наличие интернета, внезапно
Еще один минус пакетных менеджеров.
Зависимости избавляют от кучи проблем с софтом
Примеры приводить, вы конечно же не будете.
Все правильно пишешь, только гентушники это 1% от одного процента линуксоидов, у других людей есть жизнь за пределами компьютера.
когда начинаешь учить матчасть и — ВНЕЗАПНО! — понимаешь, что начиная с 7 в винде реализовано то же самое
От этого что, установка софта через пакеты с зависимостями стала доминирующим (или хотябы популярным) способом установки софта в винде?
Это все таже охеренно "хитрая" схема - я говорю что ставить софт черещ пакетный менеджер это геморой потому dependency hell, а ты говоришь что гдето в жопе винды тоже есть пакетные менеджеры. Только в линуксе это дефолтный способ ставить софт часто без особых альтернатив, а в винде маргинальный.
Если для тебя это одно и тоже, то внеси в свою матчасть учебник логики, может осилишь не такой школьный способ вести спор.
У вас какие-нибудь пригодные к обсуждению аргументы-то найдутся
Ты либо контр-аргументы приводи, либо признавай неправоту. А ты троллинг нытьем разводишь, что аргументы не нравятся.
Потому что первые 2 проблемы вообще не существуют
Серьёзно? Не, я понимаю, что лишняя сотня Мб на каждую программу при текущих ценах на SSD не критична, но ОЗУ-то не резиновая.
А любые бенефиты от экономии на спичках аннулируются как только юзер ставит flatpak.
Поставил flatpak и два приложения из него. Потерял лишних пару сотен Мб на диске, и сотню Мб оперативки, когда их запускаю. На многих десятках программ, установленных из пакетов, сэкономил на порядок больше. ЧЯДНТ?
А третья решается лишь теоретически, при условии что весь софт установлен через менеджер пакетов
Во-первых, почему вы считаете, что наличие хоть одной программы с уязвимостью автоматически делает уязвимой всю систему? А если она даже не выходит в сеть? Во-вторых, flatpak и snap имеют механизмы изоляции приложений, поэтому даже если злоумышленник воспользуется уязвимостью в устаревшей библиотеке, ему понадобится ещё и уязвимость в flatpak/snap для того, чтобы проникнуть в систему.
От этого что, установка софта через пакеты с зависимостями стала доминирующим (или хотябы популярным) способом установки софта в винде?
Да, потому что так работает MSI, и софт давно практически весь устанавливается через него, он дотаскивает через WU компоненты.
Только в линуксе это дефолтный способ ставить софт часто без особых альтернатив, а в винде маргинальный
В мелкософте, видимо, не знают, что уже написали пятую версию маргинального windows installer.
Ты либо контр-аргументы приводи
Контраргументы к потоку бреда, проистекающему из безграмотности и следующих за ней господ Даннинга и Крюгера, и плохо скрытым апелляциям то к авторитету, то к личности? )
Контраргумент к утвержениям вроде терабайт памяти был всегда, даже у БЭСМ-1, поэтому первые 2 проблемы вообще не существуют (из решаемых пакетными менеджерами)?
Но вы продолжайте перфоманс )))
Менеджеры пакетов без зависимостей. Apk \ F-Droid идеальный пример.
= таскаем ВСЕ библиотеки с собой?
Включая если надо — библиотеки для поддержки совместимости со старыми версиями (то что в том числе в Jetpack, а ранее — AppCompat входит)
И задача "обновить библиотеку с серьезной дырой" — становится… сложной?
Ну вообще то на Linux (нормальном, где от Linux не только ядро) тоже это есть — snap,flatpak и прочие AppImage. (построенные на разных принципах — AppImage — просто решение проблем с зависимости, flatpak — еще и sandbox.
Ну и — docker для не-клиентских задач.
В macOS — очень много софта — в bundle который выглядит в Finder как файл (хотя внутри это каталог) и установка — перетаскиванием в /Applications или ~/Applications. При этом нормальные инсталляторы тоже есть но обычно для случаев когда надо как то интегрироватся в систему.
Проблемы с интеграциями в хост-систему
Вот только это называется не менеджер пакетов. Это стор (пусть так и не названный в явном виде), оболочка для скачки "пакетов".
Менеджеры пакетов без зависимостей. Apk \ F-Droid идеальный пример.
Ничего идеального нет. Если у вас нет runtime или он не той версии, то ваш apk просто не запустится или будет работать немного не так. Например если opengl es не той версии или на поддерживает int16 а не int32. Или если вдруг google play не той версии или ARCore не установлена из-за недостаточной производительности системы.
Все семейство Arch забыли. А оно крупнее, чем Gentoo.
Например, для dpkg это будет dpkg –i firefox-19.0.deb, а для apt apt-get install firefox.
Я в линуксах не великий эксперт, но и не совсем лох, и тут я что-то совершенно не понял и впал в ступор. Разве apt/apt-get это не надстройка над dpkg, которая просто работает не с локальными файлами .deb, а с сетевыми репозиториями этих же файлов?
Где искать пакеты
Есть еще https://repology.org
Если .apk - то в контексте именно дистрибутивов Linux - это про Alpine. А ebuild - это вообще не пакет)
Сейчас, вроде бы еще модно-молодежно это snap, тиснул бы кто-нибудь статью тут про него уровня "для самых маленьких", а то самому по мануалам разбираться никак всё руки не дойдут.
Нафиг нужен snap который для запуска тянет с собой копию половины линукса для небольшой утилиты и при этом загаживает систему (в mount просто жесть). Appimage выглядит в этом ряду значительно привлекательней.
Докер чем не альтернатива
Как предлагаете ту же Krita в Docker использовать?)
по офф доке - https://docs.krita.org/en/untranslatable_pages/building/build_krita_with_docker_on_linux.html
P.S.
ну хоть не фотошоп и не автокад с 3d макс )))
build_krita_with_docker_on_linux.html
Сборка в docker - уже привычное зло. Но достаточно удобное ;) А для запуска придумали других инструментов, удобных именно для запуска.
Вы сами эту доку читали? Там ни слова нет про запуск Krita в Docker, только про сборку в контроллируемом окружении.
Там ни слова нет про запуск Krita в Docker
а в чем проблема после сборки запустить docker run ?
В том, что крита не запустится с какой-нибудь ошибкой в стиле "не найден дисплей"?
Передать дисплей внутрь docker не очень сложно. Но это из серии "в гамаке и стоя".
Вот именно. А присланный гайд не только никак не помогает в этом, но и вовсе не имеет отношения к заданному вопросу.
Если docker run вызывает проблемы, то увы, медицина тут бессильна
Если docker run вызывает проблемы, то увы, медицина тут бессильна
Лично вы запускали эту самую krita в docker-окружении?
И вкрутили это в свое DE, во все менюшки.. Правда?
Давайте по порядку.
- Вы предложили docker как альтернативу flatpak;
- websnow спросил, как использовать docker в совершенно типичном для flatpak сценарии;
- в ответ вы скидываете гайд по созданию контейнера для сборки программы с таким видом, будто это отвечает на заданный вопрос;
- даже если всё-таки пойти дальше, собрать программу, подобрать правильные опции для её запуска, написать для неё .desktop-файл, вы получите контейнер, занимающий в несколько раз больше места, чем и так раздутый flatpak, и программу с урезанным функционалом (как минимум, не будет подхватываться системная тема, не будет работать drag&drop между приложениями).
Вы всё ещё считаете docker адекватной заменой для flatpak? Напомню, что flatpak появился позже докера, и занял нишу, на которую тот никогда не претендовал — распространение изолированных графических приложений для ПК.
Установка пакетов во всех менеджерах производится схожим образом. Необходимо сначала скачать пакет (.deb, .rpm ...), далее установить пакет вручную, используя команду данного дистрибутива (dpkg, rpm и т.д.). Например, для dpkg это будет dpkg –i firefox-19.0.deb, а для apt apt-get install firefox
dpkg -i firefox-19.0.deb ставит пакет из файла, apt-get install firefox из репозитория. В последнем случае не нужно скачивать файл вручную вообще - apt скачает нужные файлы из репозитория и сам же вызовет dpkg для их установки.
Управление пакетами в ОС Linuх