Pull to refresh

Comments 107

В мире deb-пакетов уровень совместимости поразителен. Один и тот же пакет одинаково хорошо ставится и работает как на Debian 6, так и на Ubuntu 19.04.

Сейчас там был. Ага. Попробуйте CUDA от Ubuntu вкатить на Дебиан соответствующей версии с оф. сайта nvidia. А вот не получится. И проблема даже не в формате deb — он действительно одинаков. А в том, что в разных дистрибутивах разный набор пакетов. В принципе. А один пакет может иметь разные версии, а в манифесте deb, между прочим — хороший тон указывать версии зависимостей. Поэтому лучше уж иметь пакет под каждую версию операционной системы, зато не иметь проблем.
Как пример неграмотной запаковки — могу привести skype. Вроде есть opensuse, вроде есть rpm пакет скайпа. Устанавливаешь — не работает. Начинаешь копать. Оказывается, в rpm забыли добавить несколько зависимостей. Доустанавливаешь руками и все ок.
Еще забавнее с видеокартами radeon и amdgpu pro драйверами. Для убунты они то есть, но на дебиан (или минт)… Вставили проверку на название ОС, буквально 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

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

Ну, я мейтейнил свой комплект kernel + nginx. Но ничего интересного за давностью лет не скажу. Вроде бы — там сборка шла наружи, через штатный makefile, а потом уже отдельно происходило опакечивание софта

Как правильно — то есть как это делают настоящие мейнтейнеры — читаете от корки до корки большую часть Debian Developers' Manuals (как минимум Debian New Maintainers’ Guide, Debian Policy Manual, Debian Developer's Reference). После этого в боли и мучениях пытаетесь понять, что из этой документации уже устарело и как именно все эти мегабайты правил, советов и рекомендаций можно применить именно к вашему пакету, с учётом его индивидуальных особенностей.


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


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

Ничего он не путает. Перечитайте постановку вопроса, там не звучало "… на уровне стандарта..." — там было оголтелое утвердение, которое не соответствует действительности.
я пробовал накатить Genymotion 3, который под Ubuntu 18.04, на Ubuntu 16.04, встать то он встал, но не заработал…
Мне кажется, надо как-то придумать, как ограничить количество дистрибутивов линукса. Силы сообщества распыляются на пиление десятка, если не сотни болгеносов, вместо того, чтоб взять один дистрибутив и сделать так, чтоб там всё работало из коробки, тогда им будут пользоваться не на 0.0001% проценте дескптопов.

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


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

Прям призыв в очередному holywar-у! Придумывать ничего не надо. Есть люди (или их объединения, иногда коммерческие), которые зарабатывают деньги на поддержке своего дистрибутива. Работа эта сложная, и не всегда окупается, потому реально живых дистрибутивов не так-то и много. Ну и потом, некоторое разнообразие всё равно нужно. К примеру в Германии предпочитают SUSE, в США — Red Hat. В последнее время хорошо поднялась Ubuntu, подвинув конкурентов. Они деньги на поддержке зарабатывают, а потому и вкладывают в развитие. Реально на фанатах держится может только Arch, но это явно не ширпотреб.
Флаг «только имяркек, только хардкор» в своё время перешёл от Slackware к Gentoo, затем к Arch (в последнем случае заметно потеряв в хардкоре, да)
Есть люди (или их объединения, иногда коммерческие), которые зарабатывают деньги на поддержке своего дистрибутива.

Вот это — очень плохой конфликт интересов. Ибо чем лучше ты делаешь свой дистрибутив, тем меньше требуется поддержки, тем меньше ты зарабатываешь. Не понятно, как это исправить, разве что внести в GPL запрет на взымание денег за техподдержку…
Поверьте, проблем и так достаточно, так что сознательно их никто не делает, ну мне так кажется, по крайней мере для Linux.
Техподдержка нужна для организаций, бизнес которых зависит от этого ПО. И лицензия — типа страховка, чтобы в случае чего обратиться, чтобы «тебе сделали чтоб работало».
Альтернативный есть вариант — набирать и оплачивать штат специальстов, чтоб поддерживали твоё ПО. Этот вариант как правило выходит дороже.
Если продукт работает плохо, требуется большой штат тех.поддержки, программистов на поддержке, а это затраты. Так что делать плохо не выгодно никому, так что все вроде как стараются сделать хорошо, но не у всех получается.
Конфликт неявный. Чем больше пользуются бесплатным — тем большее количество пользователей привыкнет и захочет перейти на платный. Другой вопрос, что, да, делать бесплатную версию идеальной стимула не будет. Сносной — да. Лучше, чем у конкурентов — да. Но безглючный и идеальной — нет

Это как?
Free:
Basic features
Community support
Bugs included!
Pro:
All features full support
No.bugs


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

Действительно в Free баги будут. Хотя бы потому что — пользователи free — широкое поле для экспериментов, именно они будут получать первые нестабильные фичи и возможности, на них же они будут обкатываться. Потом после стабилизации — эти фичи и багфиксы перекочевывают в Pro-версию.
Либо в Pro версии может быть расширенный пакет опций: какие-то возможности, которые в бесплатной версии отсутствуют.

> проблемы с платным функционалом будут решаться быстрее, что логично

Вопрос приоритизации тасков, да.
Так, ну и зачем это минусовать, да ещё и гадить в карму? Спокойно дискутировать на Хабре больше не принято?
Вероятно, людям не понравилось слово «ограничить»
А… ну, это, конечно, более чем весомый повод…

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

Да, если Вы живёте в социуме, есть куча правил, писаных и неписаных, указывающих, как Вам жить, обычно для Вашего же блага и блага окружающих. От уголовного кодекса и ПДД до GPLv3 и правил поведения за столом. Срочно включаем истерику и бежим затыкать мне рот гадить в карму?
1. Наличие подобных правил ещё не повод увеличивать их количество.
2. Где вы увидели истерику?
1. Конечно не повод. Уж извините за капитанские истины, но правила появляются для увеличения всеобщего блага, предотвращения жертв, материального ущерба и иных нежелательных последствий. И да, по мере развития человечества их становится всё больше, например в 19 веке ПДД (в нынешнем виде) не существовало, а сотни лет назад можно было рабов держать. А ещё бывают несправедливые правила, и вот с ними нужно бороться.

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

Я бы вот не хотел, чтобы ко мне применялись какие-то санкции за сборку ISO-образа из LFS.
Ну, есть уголовный кодекс, а есть правила поведения за столом, на нарушения санкции разные. И да, наверное, не должно быть санкций за сборку ISO-образа из LFS. Но нужно чтобы до каждого дошло, что если хочешь помочь линуксу, не стоит пилить n+1-ый дистрибутив, а лучше поучаствовать в улучшении самого популярного. И да, желающих участвовать нужно ценить, а не бить по рукам. Как-то так, нет?

Кстати, как вариант, хотелось бы, чтоб был способ сбора статистики/метрик, сколько инсталяций по каждому дистрибутиву. И довольны ли пользователи и сколько раз день в этом дистрибутиве в среднем чего-то крашится, как быстро фиксятся баги (а не просто закрываются баг-репорты). Сразу станет ясно, чем стоит пользоваться и что стоит развивать, а что, увы, не стоит.
если хочешь помочь линуксу, не стоит пилить n+1-ый дистрибутив, а лучше поучаствовать в улучшении самого популярного
Лучше только для пользователей самого популярного дистрибутива, нужды-то у всех разные.
Кстати, как вариант, хотелось бы, чтоб был способ сбора статистики
Телеметрия на уровне ядра? :)
скольку есть инсталяций по каждому дистрибутиву
И так очевидно лидерство Ubuntu и Debian. Во втором, кстати, произошел раскол сообщества как раз из-за желания некоторых разработчиков пропихнуть единый стандарт в виде Systemd.
И сколько раз в этом дистрибутиве чего-то крашится.
Очевидно лидерство либо SUSE, либо RHEL, за поддержку которых нужно платить.
произошел раскол сообщества

И много людей на Devuan перешло?

Понятия не имею, но определенную часть разработчиков Debian потерял, причем не все из них имели что-то против Systemd, и не все перешли в Devuan.
Лучше только для пользователей самого популярного дистрибутива, нужды-то у всех разные.

1. Да, нужды у пользователей Windows тоже разные, но даже у Майкрософта не хватило ресурсов тащить Windows NT и Windows 95/8. Задумайтесь.
2. Что мешает сделать дистрибутив, максимально учитывающий нужды всех?

Телеметрия на уровне ядра? :)

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

И так очевидно лидерство Ubuntu и Debian.

А я вот думаю, что Минт, ибо Убунта в последние годы разваливается на глазах, а в Дебиане из коробки очень мало чего работает.

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

Да-да, давайте вместо того, чтоб учиться договариваться, запилим ещё один дистрибутив, ага…

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

В смысле, 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 крашатся больше, чем другие дистрибутивы или меньше?
Меньше.
UFO just landed and posted this here
UFO just landed and posted this here
Ну давайте думать в эту сторону. Мне кажется, быть контрибьютером Debian или Ubuntu — это круче, чем быть основателем JustAnother Linux, или я не прав?
Не факт. Тут сталкиваются амбиции и несовместимые характеры людей из опенсорца. Как же так — если ты контрибьютор, то ты играешь по ЧУЖИМ правилам. А в своем JustAnotherLinux — ты и есть царь и Бог.
UFO just landed and posted this here
Мне кажется, что лучше вложиться в разработку нормальных инструментов. Поглядите — вот коллеги выше по треду пишут, что правильно собрать deb/rpm пакет — это сложная задача. Это так. Получается, не хватает фреймворков, которые взяли бы задачу опакечивания и проверки этого пакета в различных окружениях с разработчика на себя. Сусевский OBS, как мне кажется, максимально близок к решению, но опять же минус, что у него фокус только на Сусе.
Божеш-мой. Ещё и nix. Ох уж эта вариативность…
«Ядро за кадром» — ну для большинства аппликух конечно можно его оставить за бортом.
«Линус с нами, проблем не будет» — проблемы будут всегда, больше или меньше. Я думаю, пока у ядра есть коммерческое применение — над ним будут работать. Большая удача, что оно появилось на значительной доле смартфонов, которые продают с предустановленным ядром. Я помню как работал Linux 15 лет назад… Это была боль.

За бортом всё равно что-то надо оставить, например саму железку.

UFO just landed and posted this here
Мне очень нравится подход приложений, написанных на Go, например Terraform: скачал один бинарник, который работает везде в рамках выбранной архитектуры и ни о чем париться не нужно, обновляешь только когда сам захочешь.
Ага, только если там завязка на системные библиотеки (типа работы с lvm), то, сорян, все равно работать не будет. Я этого хапнул со skopeo. Его приходится компилить в бинарь под каждый дистриб отдельно ((((
UFO just landed and posted this here
Ну Debian 6 не поддерживается его создателями, так что и мы в следующей версии откажемся от её официальной поддержки. А вот Red Hat 6.0 всё ещё жив и поддерживается, и наши пользователи не обрадуются, если мы его зарежем.
Enterprise пользователи очень не любят кардинально менять свою инфраструктуру. Это десктопы и ноуты живут лет по 5-7, а серваки живут десятилетиями. Им меняют процессоры, накопители, но система с данными продолжает жить.

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

Так точно, RHEL 6, который с ядром 2.6.32, а не RHL 6 с ядром 2.2.5 (страшно даже представить).

Насчет kABI: а нет возможности делать отдельно бинарь, а в DKMS модуль тоненькую прослоечку для его общения с ядром?

В эту "прослоечку" придется завернуть вообще всё, включая доступ к полям структур ядра, которые могут "съехать" (и обязательно "съедут") от одних только опций конфига сборки ядра, даже в пределах абсолютно той же версии. Именно поэтому в линуксе нужны kernel headers точно под установленное ядро и сборка драйверов из исходников. Даже костыль прикручен, в виде хеша от версии и опций конфига — modins откажется грузить драйвер собранный из чуть другого набора, даже если с ним по-факту нет проблем.

Но у nvidia же как-то получается? Поставляют скомпилированные объектные файлы и какую-то простую публичную часть.
На счёт модулей я бы сказал так: чем он проще и примитивнее, тем лучше. Если есть возможность переложить что-то на user space код, то это нужно делать.
Но увлекаться тут тоже нельзя, так как если для обработки каждого события из модуля дёргать обработчик в user space, то сильно просядет performance.
В общем драйвера — это отдельная область программирования с кучей ограничений, если сравнивать с user space.
В мире deb-пакетов уровень совместимости поразителен. Один и тот же пакет одинаково хорошо ставится и работает как на Debian 6, так и на Ubuntu 19.04.


ДА ЛАДНО?! :)
Риалли?
Ну именно для Veeam Agent for Linux для всех дистрибутивов с dpkg один пакет veeam под каждую платформу (i386 и amd64) и один пакет veeamsnap (общий, так как в сорцах). Всплыли проблемы с поддержкой именно Debian 10 в скриптах запуска сервиса, но в бэте мы это уже поправили. А пока версия 3.0 не ставится нормально только на Debian 10.
Не надо ни то, ни то.
Со snap'ом я говна поел, когда приходит разработчик, он там чего-то в docker'е запускает, но не взлетает. Оказывается он поставил его через snap и там своя отдельная песочница с ограничением прав. Приходится переустанавливать «как надо».
Т.е. — snap вероятно (как концепция, а не реализация!) хорош для прикладных вещей типа браузера, среды разработки, блокнота, мп3-плейера и пр. Но не для каких-то системных вещей.
Для системных вещей он тоже вполне подходит — LXD (а это с точки зрения технологий аналог Docker) поставляется через snap, работает без проблем.

Не настолько специалист, чтобы разбираться в сортах LXD.
Повторюсь, что идея поставлять софт в самодостаточных пакетах само по себе неплохая, но и не инновационная. С конкретной реализацией (в виде snap) были серьезные проблемы. Я уж не говорю о том, что линукс достаточно фрагментирован и на не-Убунту snap как бы не особо прижился. А лочиться только на убунте — такое себе.

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


Это, на мой взгляд, бесперспективный подход. Поддержка пакетов и патчей к ним в каждом отдельном дистрибутиве — тяжелый труд. Гораздо оптимальнее было бы прийти к какому-то общему API, общей платформе. Пусть даже это будет не одно API, а набор, чтобы цвели все цветы и чтобы у нас был выбор из 3 библиотек для воспроизведения звука и 5 библиотек для работы с USB устройствами — это будет лучше, чем то, что сейчас.


Потому что сейчас фактически единственное API — это API ядра Линукса. Сравните с Windows, где есть куча стандартных библиотек и функций на все случаи жизни с документацией в MSDN.


Я знаю про Snap, Flatpak, AppImage, nix и что там еще есть. AppImage — это не решение, у него проблемы со временем запуска и он не дает никаких API, а лишь формат упаковки файлов. Snapcraft/Flatpack — это уже что-то более рабочее.


Ну и конечно, надо лучше защищать данные от приложений. Сравните Android, где есть куча разрешений, и какую-нибудь Убунту, где проприетарное приложение с пользовательскими правами легко и спокойно читает все железные идентификаторы оборудования, MAC адреса, список окружающих вайфай точек (определяя ваше точное положение), историю, куки и сохраненные пароли вашего браузера и сохраняет их на свой сервер (а вы думали, бесплатный сыр существует?). Линукс (популярные дистрибутивы) в сравнении с Андроид или iPhone — это кошмар с точки зрения защиты данных пользователя.

>проприетарное приложение с пользовательскими правами легко и спокойно читает все железные идентификаторы оборудования, MAC адреса, список окружающих вайфай точек (определяя ваше точное положение), историю, куки и сохраненные пароли вашего браузера и сохраняет их на свой сервер

Было бы неплохо указать в таком комментарии название приложения, которое крадёт пароли пользователя (именно крадёт, а не сохраняет их на сервер с согласия пользователя в рамках функционала, заявленного для этого приложения). Приложив пруфы. Дабы пользователи знали, каким приложением пользоваться опасно.

Иначе это напоминает излюбленные завсегдатаями опеннета рассуждения про «зонды».
это будет лучше

Лучше кому? Авторам проприетарных приложений? Так вы же сами дальше пишете что они зло, крадут пароли и всё такое :)

Система безопасности на Андроиде помойка. Аргументирую. Вот ставите Вы какое-то приложение из маркета. И разработчик, чтобы не париться, тупо накидывает туда ВСЕ возможные разрешения, которые в принципе ему могут понадобиться (или не понадобиться). Ваш выбор — согласиться с ним, или нет.

Возможно сейчас стало лучше и можно на установленное приложение отзывать часть разрешений. Возможно гугль начал более серьезно подходить к аудиту приложений, чтобы разработчики не просили привилегий больше, чем им реально нужно. Но факт в том, что в истории был момент, о котором я пишу. Что сложная система привилегий приводит к тому, что ее все игнорируют. Кстати. В Винде та же самая история. Вспомните — сколько было приложений, которые требуют «Администратора», хотя по факту им достаточно разрешения на одно определенное действие.
Я уж не говорю о том, что все эти системы обычно очень грубо классифицируют все возможные действия приложения по категориям (типа «доступ к сети», «доступ к файлам», «работа с GUI», «чтение меток оборудования» и пр.), а иногда нужно чуточку более точная настройка (типа «этому приложению можно открывать только сетевой порт с номером ХХХХ»). Но лучше хоть какие-то механизмы ограничения, чем их полное отсутствие — это тоже факт.

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

В популярных дистрибутивах есть selinux и apparmor, но это не совсем то, что Вы имеете в виду. И, да, из тоже надо настраивать (
UFO just landed and posted this here
UFO just landed and posted this here
Можно в докерах запускать. Отчасти решает проблему.
Насчет сложности настройки селинукс и аппармор — да, согласен. Но это и беда того, что нет нормальных дефолтных политик, поставляемых вместе с приложением. К сожалению, здесь работает только жесткая диктатура — пока разрабов не будешь заставлять делать продукт от А до Я, то будет эта халява и все будет расползаться, т.к. будут находиться те, кто не играет по правилам и чхать хотел на эти нормативы.

Я просто запускаю скайп из-под отдельного пользователя, в своем отдельном каталоге. Чуть-чуть пришлось заморочиться с предоставлением ему доступа к иксам (к счастью, это делается одним вызовом xhost, не знаю, как будет в вейленде), и к pulseaudio (не стал заморачиваться и дал доступ всем локальным пользователям через TCP порт). Еще хотел дать ограниченный доступ к DBUS, чтобы он мог показывать уведомления, но не мог получать список wifi и bluetooth устройств, но не успел, там надо патчить прокси для dbus, а для этого его надо сначала отрефакторить, так как код там нечитабельный, а у меня руки пока не дошли.

Мой коллега из СПб (админ до мозга костей) сендбоксил скайп еще в далеком 2013:
aminux.wordpress.com/2013/06/12/skype-4-2-selinux-sandbox

Трудоемко. Кто бы опакетил подобный способ и сделал его более доступным для народа? Хотя, наверное, это уже не нужно, т.к. скайп прекрасно работает из браузера под Линем.

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

Виртуалка конечно хорошо разграничит приложения, но есть и Docker, вроде как Snappy и Flatpak решают задачу разграничения приложений, запуская их в песочнице?
Сам я этот вопрос не копал глубоко.
UFO just landed and posted this here
Во-первых, никогда не пытался использовать GUI приложение в Docker, и не уверен, что это возможно.

Это возможно. Я не скажу, что это БЕСПРОБЛЕМНО. Но завести можно при определенной сноровке.


Это я чисто теоретически рассуждаю. Например, многие даже не GUI конфигурации в Docker требуют доступа к сокету Docker'а, а это равнозначно полному доступу к хост-системе.

Именно так.

Потому что сейчас фактически единственное API — это API ядра Линукса.

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


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

В snap и flatpak тоже есть разрешения (см. interface для snap и portals для flatpak).

UFO just landed and posted this here
Как в итоге зависимости разрешаются? По пакету на дистрибутив?
Проблема с зависимостями, там где она есть, решается созданием нового пакета под дистрибутив, который решил отличиться.
Я собираюсь на centos 6 + devtoolset-7 и получаю доступ к gcc 7.3.1
Не пробовал такое, можно поресёрчить.
Судя по тексту, вся сборка на makefile построена?
Модуль ядра — классический Makefile. User space код собирается с помощью CMake.
Столкнулся недавно с Ubuntu последней версии. Сказать, что это неудобная система — ничего не сказать. Это просто сборник казусов и провалов. Я 5 раз переустанавливал ОС, что бы откомпилировать кодеки. Прошёл все муки ада, при этом. Ставил на виртуалку в божественной (в сравнении с Linux) операционной системе Windows 10, которая, в чистой установке весила 3,5 Гб на диске Ц. Содержала в себе все возможные библиотеки и сервисы и освобождала CPU на 99%, если ничего не происходит.
Кроме этого, обнаружил, что в Убунте нет ярлыков в привычном смысле слова, как в 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 скрипта компиляции — не больше.
Какой-то опыт… очень юзерский прям. Мне есть, что сказать по всем пунктам, но прежде чем начать пользоваться новым инструментом — нужно хотя бы минимально его изучить. Я помню, как я вкатывался более 10 лет назад в линукс. Тогда по счастливой случайности я выбрал дистрибутив OpenSUSE. И с тех пор сижу на нем. Были проблемы — и с автоматической установкой, и система ломалась, когда ставишь все пакеты разом. Много чего было. Да и до сих пор не все идеально. Но при наличии желания и прилежности, в принципе, все проблемы решаемы. Ценой времени.

И, да, в винде — как в закрытой системе — часть проблем В ПРИНЦИПЕ нерешаема, но, да, вЕнда изначально более дружелюбна к юзеру.
Вот в цене времени как правило и проблема. Ковыряться с системой хорошо пока это приносит интерес и не мешает основной деятельности, а когда для поддержания работы системы приходится затрачивать ресурсов больше чем на свою работу, тут уже такое…
P.S. Сам бывший линуксоид со стажем
Вот честно, не могу представить, что может заставить «линуксоида со стажем» уйти обратно на Винду, кроме отсутствия профессионально нужно софта или поддержки специфичного оборудования. Сказки про linux «постоянно требующего поддержку» давно уже остались в 2000 годах и попахивают тухлятиной…
Знаете, у меня наверное как раз середина нулевых ассоциируется с большим спокойствием и довольством системой. А дальше сплошное смутное время: отличные для своего времени третьи Кеды изничтожаются четвёртыми, свалил на Гном и Убунту. Убунту начинает с каждым релизом превращаться в жрущего как не в себя тормозного монстра (а из-за различных косяков обновляться приходится чистой установкой), ещё и заменив через пару релизов Гном на Юнити. Переход на третий Гном и кажется дебиан. Гномом можно пользоваться лишь увесив плагинами, но каждые полгода часть из них отваливается. Повсеместное внедрение SystemD, который требует отдельного изучения. Ну и периодические проблемы по мелочи.
Не спорю, можно держать себя в форме, держаться какого-то определённого дистрибутива, привыкнуть к пользовательскому окружению, которое не меняется так драматично как Кеды и Гном, но меня как пользователя в мире GNU/Linux ничего уже особо не держало. Виндовая семёрка уже была вылизана до блеска, я ушёл на неё, а через некоторое время на инсайдерскую десятку.
Значит мне повезло, xfce (на которой я сижу) весьма консервативна, и революции проходят мимо неё… ))
Поддержу насчёт XFCE, все десятки драм про разные DE за несколько лет прошли мимо меня — конфиги под GTK/Whisker/XFCE Themes кочуют со мной по компьютерам и дистрибутивам, и потребность их трогать возникает крайне редко.
Я поэтому на OpenSUSE (повторюсь).
Прошел этапы KDE — Gnome2 — Gnome3 (обплевался) и быстро свалил на Plasma

> Повсеместное внедрение SystemD, который требует отдельного изучения.

По-моему, это лучшее, что случалось с линуксом. Я просто вспоминаю мучения с Sys V Init. Это реально был ад с шелл скриптами. А сейчас… ну, терпимо. Удобно. Да, надо разбираться, но с чем не нужно разбираться? С маком? С виндой? Ну-ну.
У меня OpenSUSE кстати был первым дистрибутивом, Кеды там как раз были отполированы прекрасно, сидел на нём кажется до релиза 10.3 включительно
Думаю, с ником Вы погорячились, по крайней мере пока…
Все Ваши проблемы с 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.

Вы можете компилировать программы современным компилятором, в современном дистрибутиве, и использовать динамическую линковку со старыми заголовками glibc, чтобы ваша программа запускалась на древнегреческих дистрибутивах, но при этом не требовала собственного libc.
См. github.com/wheybags/glibc_version_header и github.com/sulix/bingcc
Only those users with full accounts are able to leave comments. Log in, please.