Вообще сделали правильно. Все, что сейсас привязано к libtorrent работает через одно место начиная эдак версии с 1.1. То сиды не находит, то скорость при 50 сидах скачет от 0 до 300 КиБ, то вообще в stalled неожиданно уходит на долгий промежуток. Крч aria2 наше все.
Вероятно, вместе с конфигами, которые не будут автоматом перезаписаны пакетным менеджером с вашего позволения.
У тебя пакетный менеджер лазит в конфиги в хомяке? Что курил?
Однако, AppImage никак не решает эту проблему, потому что он точно так же пишет конфиги в <…> /etc
Кто ж ему позволит в /etc писать-то.
в /home/$USER
Пусть пишет, мне не жалко. Все важные конфиги находятся под системой контроля версий. А конфиги а ля «какого цвета обои», которые тысячами записываются прикладным софтом, – за ними следить смысла нет.
две помойки
В системе должно быть место для помойки. Не всё и не всегда возможно держать в идеальном порядке, а возможности человеческого мозга ограничены. Попытка иметь всё под контролем - это то ли признак болезненного гиперконтроля, то ли аутизма.
Но нет, кто-то побежал в багтрекер и пожаловался, что «Gtk приложение тянет Qt зависимости»
У вас там аж две разновидности мягких зависимостей. Они там укуренные с такими претензиями?
Вот из-за такого маразма, в числе многих причин, я и слез с Дебиана. Народу толпа, а толку нихрена. В Арче намного более адекватная культура опакечивания софта.
Плюс, всегда AUR под боком. В случае чего, софт не выпиливывают из основной репы с концами - просто переносят в AUR.
Это не новости, это старости. Сто раз уже обсуждалось, что изоляция, которую навернули на флатпаке, штука довольно сомнительная, даже я бы сказал наиболее сомнительная во всей движухе. Понятно, что решили содрать подход с андроида, но там же приложения - это по сути компоненты, которые без проблем встраиваются друг в друга. Для нативных приложений линукса такой подход, очевидно, реализуется более сложно. И это порождает кучу проблем.
Предполагается сейчас, что функции, которые необходимо использовать совместно, должны быть вынесены в плагины. Для плагинов есть специальный механизм, когда они ставятся отдельным флатпак-пакетом, а любой другой желающий пакет их может подключать. Ну собственно, это опять же как в андроиде. Только в андроиде, во-первых все на java и там это намного проще, во-вторых так было сделано изначально и все приложения заточены под этот механизм.
А в линуксе мы имеем, что надо переписывать все приложения, которым нужно взаимодействие. Ведь даже shared memory закрыта для флатпак приложений (вроде, если я не попутал).
И не только приложения, например Jack звуковой сервер не может работать принципиально, потому что для обмена данными с ним используется shared memory. Поэтому его пытаются заменить на pipewire. А в большинтсве проблемных приложений даже не пытаются, просто отключают функции пока.
Но проблема то никуда, похоже, до сих пор не делась. А ведь есть ещё куча просмотрщиков картинок, которые имеют фичу «open with application» для отправки на редактирование.
Будет ли флатпак в отдельном случае видеть плагины, которые лежат снаружи тоже вопрос.
Но проблема то никуда, похоже, до сих пор не делась
Естественно. Потому что она by design.
А ведь есть ещё куча просмотрщиков картинок, которые имеют фичу «open with application» для отправки на редактирование.
Это делается через портал, открыть во внешнем приложении там не проблема. Но опять же, если в коде приложения сделано по-тупому, когда само приложение шарит по системе и ищет в чем же открыть - так работать не будет.
Будет ли флатпак в отдельном случае видеть плагины, которые лежат снаружи тоже вопрос.
Которые снаружи - он не видит. Они должны флатпак пакетом ставится. Это тоже не большая проблема совсем.
Проблема, на мой взгляд, в другом. Во всей этой концепции изоляции в песочницах и рулении разрешениями по типу андроида. И касается эта проблема и андроида в полной мере.
Вот например, ставим приложение фонарик на андроид. ВЫдается куча окон - «разрешить фонарику доступ туда», «разрешить фонарику доступ сюда» и так бесконечно. Ну это же дебилизм. Я как пользователь не должен разбираться, куда каждое приложение будет иметь доступ! Звучит странно, со мной многие тут будут спорить, но давай разберемся.
Откуда берется сама проблема необходимости ограничения доступа? От коммерческой разработки. Приложение закрыто, никто, даже магазин, не знает что там внутри. Кто будет нести ответственность за вредоносные действия? Конечно же не магазин, который продает их за деньги, ну как же можно на святого капиталиста покушаться. И поэтому ответственность переложили на пользователя - на вот, тыкай эти разрешения. Не то тыкнул - сам дурак! Зачем фонарику доступ с SMS дал? А то что без этого доступа приложение откажется работать - это мы не знаем, ваши проблемы.
А теперь возьмем линукс. Это же свободная система, вашу то мать! От кого тут надо защищаться? Зачем нужна система разрешений для свободного софта??? Для либреофиса зачем выставлять по дефолту разрешения, которые не дают документ сохранить куда надо??? Ау, каноникал со своим snap, вы там на герыче?
Для линукса, в первую очередь, нужна концепция доверенных источников приложений, в которых исключается наличие вредоносного ПО. Сделать это можно только имея свободное ПО, потому что проприетарное проверить невозможно. Ну так и система у нас ориентирована на свободное ПО.
Эта концепция и была реализована в классических репозиториях. Надо было ее не ломать, а переходя к кроссдистрибутивным пакетам, сделать изоляцию опциональной - только для проприетарщины типа Skype. А не идти по принципу «бей своих чтобы чужие боялись».
А теперь имеем в итоге вот эти проблемы, о которых ты пишешь. И это хоронит всю идею.
Какие же важные фичи тебе нужны на десктопе, к примеру?
Cамая важная - systemd поддерживается, а значит пердолинга в разы меньше.
Нормальные маны на кучу страниц, детально описывающие все аспекты конфигурации и управления.
Нормальное управление сессиями из коробки. systemd-logind - это просто наслаждение после адовой трэшины в лице ConsoleKit & Co. из прошлого десятилетия. Я рад, что теперь могу забыть про вопросы вида «А почему в моём меню нет кнопки Power Off?» или «А почему она не работает?». Да-да, я знаю что есть elogind, но зачем? Т.к. systemd может в CGroups, то logind можно настроить, что бы он убивал остатки сессии по таймауту. И это во всех случаях замечательно. Особенно, если имеешь дело с какой-нибудь плазмой, которая не дохнет даже после того как померли иксы и отказывается создавать по этой причине новую сессию. Для управления сессиями есть loginctl - и это удобно.
Пользовтельские инстансы сервисов. Это лучше ковыряния .*rc как минимум тем, что работает для всех сессий одинаково и имеет ровно один инстанс, если сессий несколько.
Нормальная, из коробки рабочая интеграция с initramfs, cryptsetup и zfs (Не совсем заслуга systemd, вернее - не только его). Что бы заставить ZFS on LUKS работать пришлось руками делать… Почти ничего.
systemd-nspawn - штука не на каждый день, но когда нужна - тогда я рад, что она есть.
Это что касается лишь небольшой части того что есть в systemd, и что я использую часто. Вообще, systemd банально приятнее пользоваться. Если тебе что-то нужно сделать с системой, то в 9 из 10 случаев для этого есть короткая человекочитаемая команда или очевидный конфиг, с предсказуемым поведением и подсказками при косяках.
И сколько оно занимает места? И навскидку можешь перечислить число этих функций?
% equery s systemd
* sys-apps/systemd-246-r2
Total files : 1813
Total size : 37.80 MiB
Стоит учесть, что компоненты systemd ещё и не статически слинкованы, так что образы, основанные на busybox и OpenRC будут весить сильно меньше. Тот же Alpine целиком весит всего 15Мб.
Не могу. Но если задача - запустить полтора сервиса, то едва ли я вижу применение хотя бы 10% systemd, особенно если конфигурация абсолютно статична.
Пока не работаешь с этим, ничего не мешает. :)
Но чем? Единственная проблема, с которой мне пишлось столкнуться - необходимость переучиваться и перекраивать свой майндсет.
Ах да, тащить из Sid-а - моветон, конечно. Но для того что бы работало на тестинге, нужны оттуда всего два пакета - libtorrent-rasterbar и qbittorrent. Такие дела.
Последняя не LTS? Ну я в принципе сам не пользуюсь промежуточными и никому не советую
А какие тогда претензии к тестингу дебиана, который вообще не релиз (а в стейбле и LTS qbittorrent тоже есть)? В апстриме проблему уже пофиксили, сейчас майнтейнеры решат ещё вопрос с python2 в build-depends и обновят.
Ещё раз: зачем? Есть systemd. Который просто работает, корректно и без всяких накидать, из коробки. Зачем его менять на что-то иное, зачем стремиться к чему-то иному?
Довольно странный подход, как по мне. Как убунта, так только LTS, как дебиан, так давайте тестинг. Да ещё в момент, когда такие кардинальные вещи происходят, как выкидывание python2, что не может не сломать что-нибудь.
И чё ты паникуешь как дефка? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956285 Любая затыка с лицензией моментально вон! В данном случае удалили что-бы внести версию в которой неоднозначность убрана в unstable и снова проводить до testing.
Не поймут ничего, а на других панику наводят, тыб ещё СЖВ приписал. Слава богу не приписал. Всё нормально.
Это что касается лишь небольшой части того что есть в systemd, и что я использую часто. Вообще, systemd банально приятнее пользоваться.
Пользую arch linux и void linux на десктопе. В первом systemd, во втором не знаю что. И я что-то как-то разницы не вижу. Поэтому и интересуюсь, именно на десктопе что ты такое вытворяешь?
нужно найти, когда и какой файл потерялся, добавить его в исходники на все релизы и платформы, а потом ещё и пересобрать пакеты так же — и это успеть до заморозки testing