Комментарии 107
Сейчас там был. Ага. Попробуйте CUDA от Ubuntu вкатить на Дебиан соответствующей версии с оф. сайта nvidia. А вот не получится. И проблема даже не в формате deb — он действительно одинаков. А в том, что в разных дистрибутивах разный набор пакетов. В принципе. А один пакет может иметь разные версии, а в манифесте deb, между прочим — хороший тон указывать версии зависимостей. Поэтому лучше уж иметь пакет под каждую версию операционной системы, зато не иметь проблем.
Как пример неграмотной запаковки — могу привести skype. Вроде есть opensuse, вроде есть rpm пакет скайпа. Устанавливаешь — не работает. Начинаешь копать. Оказывается, в rpm забыли добавить несколько зависимостей. Доустанавливаешь руками и все ок.
if (name == "ubuntu"). Та же история и с fedora, выкинь ее, выбирай только между centos и rhel — их слоган
Вы путаете наличие библиотек (зависимостей) и совместимость на уровне стандарта пакетов. У debian есть debian policy, которому криво-косо убунта соответствует (в силу того, что пакеты в основном тырит с testing). А вот в мире бешенного энтерпрайза (aka rpm) — сильнейшая фрагментация.
Это вызывает свою, отдельную боль. У debian очень стабильный интерфейс наружу (для пользователей) но куда менее стабильный интерфейс для мейнтейнеров (debhelpers), и бегать за некоторыми старыми версиями во имя "у нас нет dh_user" или "нет dh_systemd, так что писать код подкладывания unit'ов руками".
У каждого языка своя специфика. Я знаю как, но я совершенно не знаю, "правильно ли это". Я много пакетировал python, и чаще всего вам достаточно вот такого rules:
%:
dh $@ --with python3 --buildsystem=pybuildА если этого не достаточно, то никакое краткое руковоство вам не объяснит всю боль и сложность мейнтенинга.
Как правильно — то есть как это делают настоящие мейнтейнеры — читаете от корки до корки большую часть Debian Developers' Manuals (как минимум Debian New Maintainers’ Guide, Debian Policy Manual, Debian Developer's Reference). После этого в боли и мучениях пытаетесь понять, что из этой документации уже устарело и как именно все эти мегабайты правил, советов и рекомендаций можно применить именно к вашему пакету, с учётом его индивидуальных особенностей.
У Debian достаточно высокая планка качества, и планка забюрократизированности процесса в том числе. Несмотря на это, если действительно вдумчиво читать руководство, то можно понять, как собирать пакеты. Там всё-всё написано. Вот я сейчас этим как раз занимаюсь.
Ну, или можно на тяп-ляп вручную запаковать бинарный пакет для своей системы, бегло протестировать его, и заявить о поддержке.
Есть люди (или их объединения, иногда коммерческие), которые зарабатывают деньги на поддержке своего дистрибутива.
Вот это — очень плохой конфликт интересов. Ибо чем лучше ты делаешь свой дистрибутив, тем меньше требуется поддержки, тем меньше ты зарабатываешь. Не понятно, как это исправить, разве что внести в GPL запрет на взымание денег за техподдержку…
Техподдержка нужна для организаций, бизнес которых зависит от этого ПО. И лицензия — типа страховка, чтобы в случае чего обратиться, чтобы «тебе сделали чтоб работало».
Альтернативный есть вариант — набирать и оплачивать штат специальстов, чтоб поддерживали твоё ПО. Этот вариант как правило выходит дороже.
Если продукт работает плохо, требуется большой штат тех.поддержки, программистов на поддержке, а это затраты. Так что делать плохо не выгодно никому, так что все вроде как стараются сделать хорошо, но не у всех получается.
Это как?
Free:
Basic features
Community support
Bugs included!
Pro:
All features full support
No.bugs
Если продукт один и тот же, крайне накладно исправлять баги лишь в про версии. Поэтому у команды цель всегда сделать хорошо. Другое дело, что если платная версия отличается не только поддержкой, но и функционалом, проблемы с платным функционалом будут решаться быстрее, что логично
Ну и в целом, если продукт получился не очень прибыльным и популярным, сложно расчитывать на высокую замотивированность. Хотя тут есть обратная зависимость — качество продукта влияет на его популярность
Либо в Pro версии может быть расширенный пакет опций: какие-то возможности, которые в бесплатной версии отсутствуют.
> проблемы с платным функционалом будут решаться быстрее, что логично
Вопрос приоритизации тасков, да.
Потому что люди, которые пытаются указывать другим как им надо жить, мало кому нравятся.
2. Где вы увидели истерику?
2. Истерики вижу регулярно в моём профиле, в разделе «карма», уж не знаю, Ваши или чьи-то ещё.
Я бы вот не хотел, чтобы ко мне применялись какие-то санкции за сборку ISO-образа из LFS.
Кстати, как вариант, хотелось бы, чтоб был способ сбора статистики/метрик, сколько инсталяций по каждому дистрибутиву. И довольны ли пользователи и сколько раз день в этом дистрибутиве в среднем чего-то крашится, как быстро фиксятся баги (а не просто закрываются баг-репорты). Сразу станет ясно, чем стоит пользоваться и что стоит развивать, а что, увы, не стоит.
если хочешь помочь линуксу, не стоит пилить n+1-ый дистрибутив, а лучше поучаствовать в улучшении самого популярногоЛучше только для пользователей самого популярного дистрибутива, нужды-то у всех разные.
Кстати, как вариант, хотелось бы, чтоб был способ сбора статистикиТелеметрия на уровне ядра? :)
скольку есть инсталяций по каждому дистрибутивуИ так очевидно лидерство Ubuntu и Debian. Во втором, кстати, произошел раскол сообщества как раз из-за желания некоторых разработчиков пропихнуть единый стандарт в виде Systemd.
И сколько раз в этом дистрибутиве чего-то крашится.Очевидно лидерство либо SUSE, либо RHEL, за поддержку которых нужно платить.
произошел раскол сообщества
И много людей на Devuan перешло?
Лучше только для пользователей самого популярного дистрибутива, нужды-то у всех разные.
1. Да, нужды у пользователей Windows тоже разные, но даже у Майкрософта не хватило ресурсов тащить Windows NT и Windows 95/8. Задумайтесь.
2. Что мешает сделать дистрибутив, максимально учитывающий нужды всех?
Телеметрия на уровне ядра? :)
Зачем именно на уровне ядра? И можно не телеметрию, а считать число скачиваний iso-образов, если паранойя зашкаливает даже для благого дела.
И так очевидно лидерство Ubuntu и Debian.
А я вот думаю, что Минт, ибо Убунта в последние годы разваливается на глазах, а в Дебиане из коробки очень мало чего работает.
Во втором, кстати, произошел раскол сообщества как раз из-за желания некоторых разработчиков пропихнуть единый стандарт в виде Systemd.
Да-да, давайте вместо того, чтоб учиться договариваться, запилим ещё один дистрибутив, ага…
И сколько раз в этом дистрибутиве чего-то крашится.
Очевидно лидерство либо SUSE, либо RHEL, за поддержку которых нужно платить.
В смысле, SUSE и RHEL крашатся больше, чем другие дистрибутивы или меньше?
Я тоже не понял, что коллега имел в виду.
1. Да, нужды у пользователей Windows тоже разные, но даже у Майкрософта не хватило ресурсов тащить Windows NT и Windows 95/8. Задумайтесь.Windows — не свободное ПО, майкрософтовские разработчики не могут разрабатывать что душе угодно.
2. Что мешает сделать дистрибутив, максимально учитывающий нужды всех?То же, что мешает всем быть здоровыми и богатыми :) Ну то есть вот пример — SUSE не нравился NetworkManager, они написали Wicked — дебиановские мейнтейнеры бы его в апстрим, вероятно, не пропустили бы из-за завязки на YaST. Что делать?
В конце концов, кто-то может реже обновлять свой софт в соответствии, например, с версиями Glibc — им не подходит Rolling Release, кому-то наоборот нужны bleeding-edge версии библиотек, кому-то нужна определенная система инициализации, потому что у него весь софт на неё завязан, кто-то не может перейти на Wayland, и так далее, и тому подобное.
Да-да, давайте вместо того, чтоб учиться договариваться, запилим ещё один дистрибутив, ага…Там долго пытались договориться, было два голосования, разделившие голосующих пополам.
В смысле, SUSE и RHEL крашатся больше, чем другие дистрибутивы или меньше?Меньше.
Nix? (Тот, который пакетный менеджер. Можно и в тарболл запихать, и докер. Ядро остаётся за кадром, но пока Линус с нами, проблем не будет.
«Ядро за кадром» — ну для большинства аппликух конечно можно его оставить за бортом.
«Линус с нами, проблем не будет» — проблемы будут всегда, больше или меньше. Я думаю, пока у ядра есть коммерческое применение — над ним будут работать. Большая удача, что оно появилось на значительной доле смартфонов, которые продают с предустановленным ядром. Я помню как работал Linux 15 лет назад… Это была боль.
Enterprise пользователи очень не любят кардинально менять свою инфраструктуру. Это десктопы и ноуты живут лет по 5-7, а серваки живут десятилетиями. Им меняют процессоры, накопители, но система с данными продолжает жить.
Есть еще brew и nix
Насчет kABI: а нет возможности делать отдельно бинарь, а в DKMS модуль тоненькую прослоечку для его общения с ядром?
В эту "прослоечку" придется завернуть вообще всё, включая доступ к полям структур ядра, которые могут "съехать" (и обязательно "съедут") от одних только опций конфига сборки ядра, даже в пределах абсолютно той же версии. Именно поэтому в линуксе нужны kernel headers точно под установленное ядро и сборка драйверов из исходников. Даже костыль прикручен, в виде хеша от версии и опций конфига — modins откажется грузить драйвер собранный из чуть другого набора, даже если с ним по-факту нет проблем.
Но увлекаться тут тоже нельзя, так как если для обработки каждого события из модуля дёргать обработчик в user space, то сильно просядет performance.
В общем драйвера — это отдельная область программирования с кучей ограничений, если сравнивать с user space.
В мире deb-пакетов уровень совместимости поразителен. Один и тот же пакет одинаково хорошо ставится и работает как на Debian 6, так и на Ubuntu 19.04.
ДА ЛАДНО?! :)
Риалли?
Под тулзу с модулем ядра?
Со snap'ом я говна поел, когда приходит разработчик, он там чего-то в docker'е запускает, но не взлетает. Оказывается он поставил его через snap и там своя отдельная песочница с ограничением прав. Приходится переустанавливать «как надо».
Т.е. — snap вероятно (как концепция, а не реализация!) хорош для прикладных вещей типа браузера, среды разработки, блокнота, мп3-плейера и пр. Но не для каких-то системных вещей.
Не настолько специалист, чтобы разбираться в сортах LXD.
Повторюсь, что идея поставлять софт в самодостаточных пакетах само по себе неплохая, но и не инновационная. С конкретной реализацией (в виде snap) были серьезные проблемы. Я уж не говорю о том, что линукс достаточно фрагментирован и на не-Убунту snap как бы не особо прижился. А лочиться только на убунте — такое себе.
Проблема описана очень правильная. Линукс не очень-то дружелюбен к стороннему софту, особенно если он закрыт. Предполагается, что пользователь должен либо ограничиться пакетами из репозитория, а если их там нет, либо сам собирать (если он открытый) или подгонять костыли (если он закрытый) под нужный софт (а может, и поддерживать), либо обходиться без него.
Это, на мой взгляд, бесперспективный подход. Поддержка пакетов и патчей к ним в каждом отдельном дистрибутиве — тяжелый труд. Гораздо оптимальнее было бы прийти к какому-то общему API, общей платформе. Пусть даже это будет не одно API, а набор, чтобы цвели все цветы и чтобы у нас был выбор из 3 библиотек для воспроизведения звука и 5 библиотек для работы с USB устройствами — это будет лучше, чем то, что сейчас.
Потому что сейчас фактически единственное API — это API ядра Линукса. Сравните с Windows, где есть куча стандартных библиотек и функций на все случаи жизни с документацией в MSDN.
Я знаю про Snap, Flatpak, AppImage, nix и что там еще есть. AppImage — это не решение, у него проблемы со временем запуска и он не дает никаких API, а лишь формат упаковки файлов. Snapcraft/Flatpack — это уже что-то более рабочее.
Ну и конечно, надо лучше защищать данные от приложений. Сравните Android, где есть куча разрешений, и какую-нибудь Убунту, где проприетарное приложение с пользовательскими правами легко и спокойно читает все железные идентификаторы оборудования, MAC адреса, список окружающих вайфай точек (определяя ваше точное положение), историю, куки и сохраненные пароли вашего браузера и сохраняет их на свой сервер (а вы думали, бесплатный сыр существует?). Линукс (популярные дистрибутивы) в сравнении с Андроид или iPhone — это кошмар с точки зрения защиты данных пользователя.
Было бы неплохо указать в таком комментарии название приложения, которое крадёт пароли пользователя (именно крадёт, а не сохраняет их на сервер с согласия пользователя в рамках функционала, заявленного для этого приложения). Приложив пруфы. Дабы пользователи знали, каким приложением пользоваться опасно.
Иначе это напоминает излюбленные завсегдатаями опеннета рассуждения про «зонды».
это будет лучше
Лучше кому? Авторам проприетарных приложений? Так вы же сами дальше пишете что они зло, крадут пароли и всё такое :)
Возможно сейчас стало лучше и можно на установленное приложение отзывать часть разрешений. Возможно гугль начал более серьезно подходить к аудиту приложений, чтобы разработчики не просили привилегий больше, чем им реально нужно. Но факт в том, что в истории был момент, о котором я пишу. Что сложная система привилегий приводит к тому, что ее все игнорируют. Кстати. В Винде та же самая история. Вспомните — сколько было приложений, которые требуют «Администратора», хотя по факту им достаточно разрешения на одно определенное действие.
Я уж не говорю о том, что все эти системы обычно очень грубо классифицируют все возможные действия приложения по категориям (типа «доступ к сети», «доступ к файлам», «работа с GUI», «чтение меток оборудования» и пр.), а иногда нужно чуточку более точная настройка (типа «этому приложению можно открывать только сетевой порт с номером ХХХХ»). Но лучше хоть какие-то механизмы ограничения, чем их полное отсутствие — это тоже факт.
Тем не менее эти разрешения там есть, а в неофициальных сборках Андроид есть способы их отбирать или подсовывать фейковые данные вместо настоящих. В популярных дистрибутивах Линукса этого нет.
Насчет сложности настройки селинукс и аппармор — да, согласен. Но это и беда того, что нет нормальных дефолтных политик, поставляемых вместе с приложением. К сожалению, здесь работает только жесткая диктатура — пока разрабов не будешь заставлять делать продукт от А до Я, то будет эта халява и все будет расползаться, т.к. будут находиться те, кто не играет по правилам и чхать хотел на эти нормативы.
Я просто запускаю скайп из-под отдельного пользователя, в своем отдельном каталоге. Чуть-чуть пришлось заморочиться с предоставлением ему доступа к иксам (к счастью, это делается одним вызовом xhost, не знаю, как будет в вейленде), и к pulseaudio (не стал заморачиваться и дал доступ всем локальным пользователям через TCP порт). Еще хотел дать ограниченный доступ к DBUS, чтобы он мог показывать уведомления, но не мог получать список wifi и bluetooth устройств, но не успел, там надо патчить прокси для dbus, а для этого его надо сначала отрефакторить, так как код там нечитабельный, а у меня руки пока не дошли.
aminux.wordpress.com/2013/06/12/skype-4-2-selinux-sandbox
Трудоемко. Кто бы опакетил подобный способ и сделал его более доступным для народа? Хотя, наверное, это уже не нужно, т.к. скайп прекрасно работает из браузера под Линем.
Сам я этот вопрос не копал глубоко.
Во-первых, никогда не пытался использовать GUI приложение в Docker, и не уверен, что это возможно.
Это возможно. Я не скажу, что это БЕСПРОБЛЕМНО. Но завести можно при определенной сноровке.
Это я чисто теоретически рассуждаю. Например, многие даже не GUI конфигурации в Docker требуют доступа к сокету Docker'а, а это равнозначно полному доступу к хост-системе.
Именно так.
Потому что сейчас фактически единственное API — это API ядра Линукса.
Я бы сказал, сейчас де-факто стандартная платформа кроме этого включает PulseAudio и systemd как минимум.
Ну и конечно, надо лучше защищать данные от приложений. Сравните Android, где есть куча разрешений
В snap и flatpak тоже есть разрешения (см. interface для snap и portals для flatpak).
в состав модуля входит модуль
Как в итоге зависимости разрешаются? По пакету на дистрибутив?Проблема с зависимостями, там где она есть, решается созданием нового пакета под дистрибутив, который решил отличиться.
Я собираюсь на centos 6 + devtoolset-7 и получаю доступ к gcc 7.3.1Не пробовал такое, можно поресёрчить.
Судя по тексту, вся сборка на makefile построена?Модуль ядра — классический Makefile. User space код собирается с помощью CMake.
Кроме этого, обнаружил, что в Убунте нет ярлыков в привычном смысле слова, как в Windows. В 2019 году операционке так и не сделали банальных ярлыков на рабочий стол? После этого можно даже не пытаться говорить о том что эту ОС хоть как-то можно использовать дома.
Установка Ubuntu №1 — операционке стало мало 20Гб, которые я ей выделил. Дал ей ещё 5Гб, — этого хватило на копирование 500Мб файлов из Windows в Ubuntu. Причём пишет: свободно 1,5 Гб (когда я ей на 5Гб диск увеличил) и всё равно не копирует файлы дальше. Увеличил ещё на 5 и потом ещё на 10Гб. Скопировал 2Гб файлов, которые хотел и обнаружил, что нужно обновить проект. Удалил его, начал копировать заново — места опять нет! И это на чистой Убунте без доп. ПО. Мне не хватило 50Гб диска, что бы скопировать ей на рабочий стол 5Гб. файлов.
Удалил Ос.
Установка Ubuntu №2 — нужен был Python просто для компиляции, а в ОС по умолчанию стоит python3. Откуда мне было знать, что там всё держится на Python? Удалил python3 — интерфейс перестал грузиться совсем. Установки никакие не шли. Восстановить не удалось, миллион разных зависимостей, которые никак не исправить.
Удалил Ос.
Установка Ubuntu №3 — При компиляции, мне по какой-то причине написало, что у меня (единственного админа) не хватает прав на выполнение чего-то там. Ну я загуглил — оказывается можно дать себе же права Super User. Ну я дал. Скопировались файлы при компиляции под этим SU. Опять пишет нет доступа — т.е. уже у SU — нет доступа. Перезагрузил ОС — вообще никак не могу подступиться к файлам, которые скопировались в прошлый раз. Даже под SU. Всё… главная папка проекта заблокирована.
Удалил Ос.
Установка Ubuntu №4 — воспользовался автоустановщиком VmWare. Установилась полная версия Ubuntu без спроса. Создались пути до рабочего стола и домашней папки с пробелами и на русском языке, что недопустимо для скриптов компиляции кодеков. Это жесть… автоматизация в худшем её виде. Почему автоматически система создаётся не так, как в ручную?
Удалил Ос.
Установка Ubuntu №5 — сейчас. Ещё особо ничего не делал. Берегу её, как патрон в автомате. Полюбому хватит на 1-2 скрипта компиляции — не больше.
И, да, в винде — как в закрытой системе — часть проблем В ПРИНЦИПЕ нерешаема, но, да, вЕнда изначально более дружелюбна к юзеру.
P.S. Сам бывший линуксоид со стажем
Не спорю, можно держать себя в форме, держаться какого-то определённого дистрибутива, привыкнуть к пользовательскому окружению, которое не меняется так драматично как Кеды и Гном, но меня как пользователя в мире GNU/Linux ничего уже особо не держало. Виндовая семёрка уже была вылизана до блеска, я ушёл на неё, а через некоторое время на инсайдерскую десятку.
Прошел этапы KDE — Gnome2 — Gnome3 (обплевался) и быстро свалил на Plasma
> Повсеместное внедрение SystemD, который требует отдельного изучения.
По-моему, это лучшее, что случалось с линуксом. Я просто вспоминаю мучения с Sys V Init. Это реально был ад с шелл скриптами. А сейчас… ну, терпимо. Удобно. Да, надо разбираться, но с чем не нужно разбираться? С маком? С виндой? Ну-ну.
Все Ваши проблемы с linux, от нежелания элементарно предварительно прочитать доки/форумы о принципиально другой ОС и стремления решить задачу «нахрапом», по шаблонам Виндовс.
Кроме этого, обнаружил, что в Убунте нет ярлыков в привычном смысле слова, как в Windows. В 2019 году операционке так и не сделали банальных ярлыков на рабочий стол? После этого можно даже не пытаться говорить о том что эту ОС хоть как-то можно использовать дома.В Gnome, на котором сейчас строится Ubuntu, ярлыки всегда были до последнего времени но убраны разработчиками, решение действительно странное, но они так «видят». Насколько я знаю, включаются сторонними решениями.
Установка Ubuntu №2 — нужен был Python просто для компиляции, а в ОС по умолчанию стоит python3. Откуда мне было знать, что там всё держится на Python? Удалил python3 — интерфейс перестал грузиться совсем. Установки никакие не шли. Восстановить не удалось, миллион разных зависимостей, которые никак не исправить.Уверен, пакетный менеджер Вас предупреждал что на python куча зависимостей, но Вы решили что умнее. Ну что же, сами себе злобный буратино.
По остальным пунктам, слишком сумбурно и эмоционально-трудно что нибудь диагностировать.
Банально но… учите матчасть…
Почти классический вопрос — а вы про какой рабочий стол говорите?)
Знаю, что гном, но вопрос актуальности не теряет
Убунта хороша как система, в которой после установки все есть. И там действительно все есть. Кроме злосчастных кодеков. Браузер, офис, плеер и магазин приложений. А большего и не надо.
Если она в таком ключе не подошла, тогда она потребует технических скиллов, как и любой другой линукс дистрибутив. И там уже нужно знать, что трогать, а что нет. Вы ведь системные библиотеки в винде не удаляете, по той же причине не стоит трогать питон. Другое дело, что проку вам от системных библиотек? А в линуксе вы можете на питоне писать и редактировать системные скрипты. И это будет нативнее, чем на винде.
Все ваши проблемы говорят лишь о том, что подход виндовс — попробовать все кнопки подряд тут не работает)
С теми же правами, есть команда судо, которая дает права су на время выполнения программы или время сессии терминала. И это первое, что выдает гугл, как правило)
Вроде все мелочи, а бездумные неосознанные действия в итоге приводят к проблемам.
90% «мастеров», покупая клей не утруждают себя чтением инструкции на упаковке, яже Мастер, я Знаю… потом их поделие благополучно разваливается и они плюются на клей — «авно», вот Я с предыдущим работал — от то Клей. А производитель не просто так инструкцию пишет, даже у однотипных клеев есть свои нюансы применения, без соблюдения которых они, странно, не работают…
Не сразу догнал. Это типа пост-жалоба на линуксовую инфраструктуру?
Если публикуете приложение, лучше просто архивом c бинарниками приложения в tar.bz2/lzma выложить как браузеры делают. Пакетные менеджеры это вообще не площадка для публикаций приложений.
А если приложению нужна какая-то системная библиотека? Предлагаете кидаться архивами с полной фс? Мегабайт так на 500?
П.с. минус не я ставил, но позиция у Вас какая-то агрессивная прям
папку с программой — в /opt
desktop файл — в домашнюю папку пользователя (если приложение с гуем), или линк в /usr/local/bin если без гуя, или если только себе надо то вообще в профаил.
Блин этож никсы, а не виндоус — что где намусорено будет?
По поводу системных библиотек я не очень понял, если имеются в виду библиотеки из gtk, kde и прочего (как в гнутом софте из репозиториев) то тут просто ничего не поможет уже, такие приложения в снапе тянут с собой каждая половину системы, вплоть там до xcursor и mesa.
Но я все таки понимаю тут свое приложение какое-то (наверное проприетарное), проще и правильней собирать его так что бы оно из папки из своей работало. глибси (и что там еще может быть из таких "системных" библиотек) использовать те что в основных дистрибутивах гарантировано есть.
Как с бинарником поступить я (пользователь линукса) сам решу, если я маинтейнер — заменю либы на симлинки, запакую, добавлю в реп. Если просто-пользователь — просто куда мне надо вытряхну и просто создам кнопку.
то тут просто ничего не поможет уже, такие приложения в снапе тянут с собой каждая половину системы, вплоть там до xcursor и mesa.
Не уверен, что это правильный сценарий, тем более, если приложению нужна интеграция с другими частями системы. Как один из кейсов — у меня стоит Телеграм клиент. В виде отдельного бинарника. Видимо, со своими библиотеками Qt и шрифтами. И что же? Оказывается, что если через него протыкивать ссылку, то запускается гугл хром НЕ В ТОМ окружении. Прикиньте? А я-то думал, что я схожу с ума. Оказывается, что нет.
Как с бинарником поступить я (пользователь линукса) сам решу, если я маинтейнер — заменю либы на симлинки, запакую, добавлю в реп. Если просто-пользователь — просто куда мне надо вытряхну и просто создам кнопку.
ну, ок
Погодите. А настройки? А файлы данных? Я хочу опцию, что приложение, когда удаляется, то или оставляет их (один кейс — например, для обновления версии), или удаляет (если я хочу почистить хвосты).
Не совсем врубаюсь о чем разговор. Все пользовательские настройки приложения лежат в домашней папке и они не удаляются при удалении приложений.
Не уверен, что это правильный сценарий, тем более, если приложению нужна интеграция с другими частями системы. Как один из кейсов — у меня стоит Телеграм клиент.. В виде отдельного бинарника. Видимо, со своими библиотеками Qt и шрифтами. И что же? Оказывается, что если через него протыкивать ссылку, то запускается гугл хром НЕ В ТОМ окружении. Прикиньте?
Так это ты про снап или флатпак какой нибудь — какое они вообще к разговору имеют отношение? Я говорю про классические позикс подходы, самые что нинаесть стандартные.
Если тебя задело отношение к маинтейнерским репозиториям — как к ним еще относиться если это не гитхаб тебе какой нибудь. Это комьюнити которое самостоятельно программы подбирает, собирает, обновляет. Туда нет доступа — ты как разработчик не можешь туда ничего опубликовать ничего обновлять, кроме того их политика может быть такова что твое приложение вообще туда в принципе попасть не может. Маинтейнерские репозитории это не апстор, а компоненты ОС. Макось например тоже из коробки имеет и питон и эмакс и кучу свободных библиотек и приложений, тех версий которые маинтейнеру (в лице эпл) надо, и обновляемые на те версии которые надо, но это не единственный способ получения приложений на макоси и не сказать что бы те другие способы испытывали какие то проблемы с интеграцией. Позтикс он и есть позикс, его не дураки придумывали.
Так это ты про снап или флатпак какой нибудь — какое они вообще к разговору имеют отношение? Я говорю про стандартный позикс методы, самые что нинаесть классические.
Нет, не флатпак и не снап. Просто бинарь с офсайта.
Если тебя задело отношение к маинтейнерским репозиториям
Я спокойно реагирую )
Макось например тоже из коробки имеет и питон и эмакс и кучу свободных библиотек и приложений, тех версии которые маинтейнеру (в лице эпл) надо, и обновляемые на те версии которые надо, но это не единственный способ получения приложений на макось и не сказать чтоб эти другие приложения испытывали проблемы с интеграцией в систему.
Все верно. То что мне было нужно — я на мак притаскивал через brew.
См. github.com/wheybags/glibc_version_header и github.com/sulix/bingcc
Linux многоликий: как работать на любом дистрибутиве