LINUX.ORG.RU

Pipewire - неизбежная... победа!

 , ,


5

2

Есть snap, flatpak, wayland. Вроде хорошее дело, но - они добавляют изоляцию между приложениями, и такие штуки как jack, pulseaudio уже не могут работать как раньше. Надо что-то решать. И тут появляется надежда - pipewire. Но надежда ложная, потому что это катастрофа!

Нет, надежда все-таки есть.

Вот мои претензии (которые в итоге разрешились):

1. Обязательный ресемплинг. Как известно, pulseaudio поддерживало две частоты дискретизации микшера - основную и альтернативную. Это позволяло, в случае воспроизведения например только музыки со spotify переключать микшер на частоту дискретизации потока и УБРАТЬ ресемплинг! Если воспроизводит только одно приложение, ресемплинга быть НЕ ДОЛЖНО! Потому что он не нужен. Pipewire не позволяет, и похоже что реализовать это в той архитектуре, которую заложили, будет весьма непросто. На практике он всегда делает ресемплинг и всегда портит звук.

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

Переключение РАБОТАЕТ уже сейчас, на версии из Git! На релизе 0.3.33 у меня не работает.

КАК СДЕЛАТЬ:

В pipewire.conf пишем:

default.clock.rate          = 48000
default.clock.allowed-rates = [ 44100, 48000 ]

Можно перечислить в allowed-rates до 16 значений. Все!

ТЕПЕРЬ - если воспроизведения не было, и запустить на воспроизведение ОДНО приложение, pipewrire будет переводить себя и звуковую карту на частоту дискретизации этого приложения, и ресемплинга НЕ БУДЕТ.

2. При работе с jack клиентами может меняться размер буфера. Занавес! То есть я играю на гитаре, и тут мне меняют размер буфера? А ничего что это приведет к слышимому и чувствуемому изменению задержки звука? Как играть??? Так НЕЛЬЗЯ ДЕЛАТЬ, а надо делать ровно наоборот. Я уже молчу про то, что изменение на лету размера буфера может просто крашануть jack приложение, которое такого бреда не ожидало!

3. Для того, чтобы вообще хоть как-то задать размер буфера для jack клиентов, надо запускать приложение с переменной окружения PIPEWIRE_LATENCY. То есть мне теперь все приложения из консоли стартовать? Или все desktop файлы править? С настоящим jack это решается элементарно - программой управления типа qjackctl. Там просто выбирается какой буфер, и все приложения используют его. Должно быть ВОТ ТАК.

Решение:

pw-metadata -n settings 0 clock.force-quantum <size>

устанавливает фиксированный размер буфера.

Или в jack.conf:

node.lock-quantum = true

4. Нельзя нормальным образом поменять частоту дискретизации при работе с jack клиентом. Используется та, на которую настроен pipewire своим конфигом. С нормальным jack частота просто выбирается в qjackctl. А с pipewire что, мне править конфиг и перезапускать его, или как?

Решение, можно менять на лету:

pw-metadata -n settings 0 clock.force-rate <samplerate>

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

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

★★★

Последнее исправление: James_Holden (всего исправлений: 4)

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

Я сразу в ОП написал. Просто юникс-вытираны не осилили чтение, поэтому даже не почитали что такое юникс вей. Программные продукты у него. В юникс вее. Давно так не ржал.

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

Ты ишо и малолетка. Ну тохда усё ясно. Ну загугли, чо не как пацан? :D :D :D

С уваженьем. Дата. Подпись.
Отвечайте нам, а то,
Если Вы не отзовётесь,
Мы напишем… в Спортлото!
vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

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

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

То что ты внезапно перешёл на «ты» опустим, я тоже по дефолту тут часто тыкаю. Это ладно.

James_Holden ★★★
() автор топика

В автомобильной промышленности все эти минусы незаметны.

Вассисуалий.

anonymous
()

@kott @eternal_sorrow @fernandos

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

Поставил pipewire-pulse и арчевский дропин для pipewire-jack, который перенастраивает ld.so чтобы все jack приложения сами, по умолчанию цеплялись к pipewire без всякого pw-jack. Это дало возможность запускать все приложения как и раньше, из GUI, без консоли.

Как оказалось, программы для настройки джека - qjackctl и cadence хорошо рулят графом соединений между нодами, и самое главное - позволяют на лету переключать размер буфера. Что дает возможность не ставить переменную окружения PIPEWIRE_LATENCY и опять же решает вопрос с запуском не из консоли.

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

С частотой дискретизации полная задница. Ее тупо можно поменять только через конфиг и перезапуск pipewire. Пока сделал компромиссный вариант - установил ее в 96000. Потому что я с jack приложениями так работал, а для pulseaudio приложений ресемплинг на 96000 тоже предпочтительнее. Меньшее зло.

В целом все это выглядит практически как jack c мостами pulseaudio. Снаружи то же самое почти.

В дальнейшем буду изучать внутренности и пытаться сделать что-то с переключением частоты дискретизации.

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

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

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

Фиксированная частота дискретизации это компромиссное решение для того, чтобы обеспечивать одновременно низкие задержки как в jack и удобство работы пользовательских клиентов как в pulseaudio. В jack тоже частота дискретизации фиксирована (то что её можно изменить через утилиту а не конфиг, ничего особо не меняет). Тут расчёт идёт на то, что если ты профессионал и хочешь избежать ресемплинга, ты сможешь обеспечить чтобы частота в клиенте и сервере совпадала. А для обычного пользователя это вообще не важно.

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

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

Замечательно, не знал.

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

Фиксированная частота дискретизации это компромиссное решение для того, чтобы обеспечивать одновременно низкие задержки как в jack и удобство работы пользовательских клиентов как в pulseaudio

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

В jack тоже частота дискретизации фиксирована

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

В jack (и pipewire) все наоборот - сервер при запуске устанавливает частоту и дальше все должны подстраиваться под него.

Для jack приложений + настоящий jack это не проблема, потому что при работе в профессиональных приложениях ты ставишь ЧЕРЕЗ УТИЛИТУ нужную частоту, с которой у тебя дорожки в DAW, затем запускаешь jack и так работаешь.

Для pipewire это двойная проблема. pulseaudio приложения больше не могут заставить сервер на лету выбирать оптимальную частоту. Перед запуском jack приложения я не могу из утилиты выбрать нужную частоту сервера. Только через конфиг и перезапуск. А потом после работы - обратно, чтобы ютубчик не ресемплировался в 96000 Гц.

Но я конечно так прыгать не буду - я все загоняю в 96000. Хреново, но терпимо.

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

Полная катастрофически бредовая чушь. Если у тебя музычка имеет частоту дискретизации 44100 Гц а pipewire - 48000 Гц то ты никак не можешь избежать ресемплинга и при этом сделать чтобы частота в клиенте и сервере совпадала. Хоть ты об бетон расшибись.

А для обычного пользователя это вообще не важно.

А мне потребности всяких хомячков не важны. Мне работать на компе надо.

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

Вот это лол. Конечно я никакой диссер не удалял, тем более при помощи Kate. Я же не идиот. Неужели ты решил что это реальная история?

Неожиданно. Выглядит примерно так:

- надо всем мужчинам в нашем городе отрезать мпх, так как они могут изнасиловать мою дочь!

- а что, ваша дочь такая красавица?

- лол, нет у меня никакой дочери, я что, идиот.

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

Это выглядит не так. А вот так: есть две вещи, извилины серого вещества и абстрактное мышление. И есть острый дефицит этих двух вещей на ЛОРе.

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

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

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

Ну разработчики pulseaudio не смогли. Поэтому pulseaudio не используется профессионалами.

Она не может быть не фиксирована там.

В pipewire тоже не может быть, ведь pipewire является реализацией jack в том числе.

потому что при работе в профессиональных приложениях ты ставишь ЧЕРЕЗ УТИЛИТУ нужную частоту, с которой у тебя дорожки в DAW

То что в pipewire ещё не запилили эту фичу, не значит что это невозможно. Как минимум можно редактировать конфиг в хомяке (~/.config/pipewire/pipewire.conf) и там задавать частоту как тебе нужно. Можно делать это утилитой и ей же перезапускать демон pipewire.

Полная катастрофически бредовая чушь.

Не чушь. Речь шла про профессионалов и профессиональные приложения. А не про музычку 44100 Гц.

А мне потребности всяких хомячков не важны.

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

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

Ну разработчики pulseaudio не смогли.

Ultra low latency is not a design goal. Это из доков.

В pipewire тоже не может быть

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

Речь шла про профессионалов и профессиональные приложения

Ох лол, я открою тебе страшный секрет. Профессионалы в профессиональных приложениях делают музычку 44100 Гц. Внезапно. Ну вот такие в линуксе профессионалы. Те настоящие профессионалы что с DXD форматами они на несколько иных ОС сидят.

И тогда придется ставить частоту сервера 44100. И перегонять ютуб из 48000 в 44100 что совсем не айс.

Тебя это не устраивает - не используй pipewire.

Не могу - альтернатив нет. Разрабатывать времени нет.

В флатпак при желании можно пробросить доступ к jack, просто это костыльно делается.

Это никак не делается. В старом flatpak это работало, потом стало невозможным. Разработчики jack официально клали болт. Да ничего они и не сделали бы.

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

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

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

Монолитная архитектура это классические репы

Правильно. Вся нагрузка на мейнтейнеров.

Модульная - это флатпак.

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

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

Правильно, но у нас очень жесткий дефицит тех кто может включать башку и при этом как-то повлияет на картину в целом (имеет имя, время и желание на это). Так что отказ от монолита - шаг в бездну. Сам Линукс и взлетел, а не стал Minix-ом, который спустя много лет занял очень специфичную нишу железного бекдора в интеловских процах именно за счёт отказа от модульности.

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

Вся нагрузка на мейнтейнеров.

Вся нагрузка на разработчиков

Ты задаешь интересный вопрос. Но давай разберемся.

а на системных, которые ключевые штуки пилят, вроде звуковой подсистемы или видеоподсистемы

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

А теперь внимание вопрос, кого у нас больше, разработчиков или мейнтейнеров

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

но у нас очень жесткий дефицит тех кто может включать башку и при этом как-то повлияет на картину в целом (имеет имя, время и желание на это)

Согласен. Интересная мысль.

Так что отказ от монолита - шаг в бездну

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

Сейчас некий переломный момент. Вяленый постепенно одерживает победу. Флатпако-снап не особо одерживает. Контейнеры на серверах победили. Атомарная базовая система - на уровне экспериментов пока.

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

Тут важно еще вот что. Snap по сути собирается на базе deb. То есть внутри сборочной среды все равно остаются старые пакеты. Flatpak - нет, собирает с нуля сам в своей песочнице. Он как бы в стороне. Атомарная базовая система (OSTree) - тоже старыми пакетами собирается, а иначе замучаешься ее поддерживать. Докер - внутри опять же пакетная система. Надо же как-то ставить зависимости в контейнере.

То есть если не брать флатпак, который стоит неким особняком (а точнее flathub, сам флатпак не запрещает все хоть из deb перепаковывать), то вся новизна это просто слой поверх старой пакетной системы. Слой, который скрывает от пользователя пакеты и зависимости. Но не от разработчика.

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

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

Вообще-то надо. Разработчик по дефолту умеет собирать только своё приложение. Совсем не факт, что у него хватает квалификации правильно собирать все зависимости.

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

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

Вот за это долбят флатпак по сравнению со снапом. Там ты по сути берешь убунту, ставишь через apt все зависимости для сборки, собираешь приложение как для deb пакета обычного, и потом все упаковывается в Snap пакет. Это проще.

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

Ну я думаю что это редко когда бывает так уж сложно. Это не сборка базовой системы с нуля.

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

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

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

Проще говоря - все зависимости он собирать не будет. Только то, чего не хватает в рантайме.

Если у тебя Qt приложение, то Qt собирать не надо.

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

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

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

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

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

Проблемы которые ты обозначил - проистекают от разницы между целевой системой и системой разработчика. Флатпак, снап, как и докер, специально сделаны так чтобы этой разницы не было автоматически. Поэтому собрать так, чтобы «нормально работает только на машине разработчика» можно только с классическими репами.

Почему я и долблю что это фуфло устарело.

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

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

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

Не позорься, OBS запускается нативно в Wayland, а захват экрана был запилен еще раньше, сразу после появления необходимого механизма в pipewire.

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

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

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

Т.е. на 11 году разработки они смогли сделать захват экрана и на 13 году прикладной софт таки смог в него. Что же, это похвально, ещё лет 10 и Wayland-ом станет можно пользоваться.

Вcё правильно. Иксы стали юзабельны тоже когда им 25+ лет исполнилось.

PS

Как раз ещё через 30 лет сделают полный интерфейс на веб технологиях. Когда ядро будет через электрон всё рендерить.

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

Как раз ещё через 30 лет сделают полный интерфейс на веб технологиях.

Скорее всего …

Поживем, увидим

К сожалению большая проблема - ДУРАКИ

А их победить НЕ ВОЗМОЖНО
anonymous
()

@kott @Harald

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

Есть программа Helvum, для работы с pipewire. Она на расте. Под арч пакета нет, на флатхабе пока нет. Я думал - ну блин, сейчас с сырцов растовое приложение собирать. У меня и раста нету, вкорячивать все это… А растовый тулчейн это не FASM мягко говоря.

Но - у них есть конфиг для faltpak-builder. Итого - вводим две команды:

flatpak install org.freedesktop.Sdk.Extension.rust-stable//20.08
flatpak-builder --install flatpak-build/ org.freedesktop.ryuukyu.Helvum.json

Первая ставит «гномовский» Sdk и добавляет туда раст, вторая - собирает и сразу ставит флатпак пакет.

Во время сборки, что характерно, @peregrine, все зависимости тянутся растовым пакетным менеджером языка. Вся сборка идет во флатпаковой песочнице, потом это все элементарно вычищается с диска и не размазывается по хостовой системе. Собрал и забыл.

После установки смело сносим Sdk, зачем растом место тратить:

flatpak uninstall org.gnome.Sdk

@Harald, сравни теперь это со сборкой deb пакета. Тебе бы пришлось ставить -dev зависимости в основную систему, ставить раст в основную систему. А потом после сборки, если ты не хочешь чтобы это отсвечивало в системе, все это удалять по пакетику. С флатпаком, мягко говоря, несколько проще.

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

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

Есть такая штука, называется DeepPavlov.

А причем тут зависимости? Она не работает из-за железа. Это не относится к предмету разговора.

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

Тебе бы пришлось ставить -dev зависимости в основную систему,

И что? Если ты разработчик, то это нормально иметь -dev пакеты в системе. Зачем их удалять.

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

все это удалять по пакетику

в makepkg есть: -r, –rmdeps Удалить установленные зависимости после сборки

если забыл указать -r, то [[ -n $(pacman -Qdtt) ]] && sudo pacman -Rsn $(pacman -Qdttq) || echo "no orphans to remove"

для остальные дистров наверное такое же есть.

anonymous
()
Ответ на: комментарий от James_Holden

@Harald, сравни теперь это со сборкой deb пакета. Тебе бы пришлось ставить -dev зависимости в основную систему, ставить раст в основную систему. А потом после сборки, если ты не хочешь чтобы это отсвечивало в системе, все это удалять по пакетику. С флатпаком, мягко говоря, несколько проще.

И зачем это всё? Я бы одной командой запустил бы multipass с Ubuntu LTS для сборки.

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

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

И зачем это всё? Я бы одной командой запустил бы multipass с Ubuntu LTS для сборки.

Я с вас просто шизею. Запускать виртуалку для сборки. Ну запускай.

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

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

И запускаю. Так проще и логичнее.

Возиться с твоим предметом обожания тем более желания нет. Пользовался до 2021 года — ужас.

И про расход места тоже весьма сомнительно.

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

Скажи прямо - ты просто мазохист. Я больше не знаю как объяснить желание собирать на виртуалке.

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

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

А вы ковыряйтесь в своих тупых deb помойках на виртуалках.

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

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

Смотри в зеркало. Прям канонический фанатик по всем пунктам.

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

Тем не менее, он скорее прав, чем нет. Каждый раз, когда я запускаю свой emacs, вместе с ним запускаются сотни режимов, т.е. какой-то совершенно непроверенный код из Интернета, который имеет доступ ко всему. Так себе подход.

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

Прям канонический фанатик по всем пунктам.

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

А deb фанатики корячатся с этим недоразумением и считают что так и надо. Мазохисты-фанатики чистые.

Я же не вчера на линукс перешел, увидел флатпак и все, как утенок - это единственно верное решение! Идите в зад!

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

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

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

Это фанатики такие же, как фанатики Ленина и СССР. В голову вбито и все, теперь уже мозг не работает. Война - это мир, свобода - это рабство, незнание - сила.

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

Каждый раз, когда я запускаю свой emacs

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

Пока во флатпаке это не решено никак, просто дается полный доступ к хомяку.

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

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