Создать приложение для резервного копирования, работающее на любом дистрибутиве — задачка непростая. Чтобы обеспечить работу Veeam Agent for Linux на дистрибутивах от RHEL 6 и Debian 6, до openSUSE Leap 15.1 и Ubuntu 19.04 приходится решать спектр проблем, особенно если учесть, что в состав программного продукта входит модуль ядра.
Статья создана по материалам выступления на конференции LinuxPiter 2019.
Linux — это не просто одна из самых популярных ОС. По сути, это платформа, на базе которой можно сделать что-то уникальное, что-то своё. Благодаря этому у Linux множество дистрибутивов, которые отличаются набором программных компонентов. И тут возникает проблема: чтобы программный продукт функционировал на любом дистрибутиве, приходится учитывать особенности каждого.
Пакетные менеджеры. .deb vs .rpm
Начнём с очевидной проблемы распространения продукта для разных дистрибутивов.
Самый типичный способ распространения программных продуктов — это выложить пакет на репозиторий, чтобы встроенный в систему пакетный менеджер смог его оттуда установить.
Однако популярных форматов пакетов у нас два: rpm и deb. Значит, придётся поддержать каждый.
В мире deb-пакетов уровень совместимости поразителен. Один и тот же пакет одинаково хорошо ставится и работает как на Debian 6, так и на Ubuntu 19.04. Стандарты процесса построения пакетов и работы с ними, заложенные в старых Debian дистрибутивах, остаются актуальными и в новомодных Linux Mint и elementary OS. Поэтому в случае Veeam Agent for Linux достаточно одного deb-пакета для каждой аппаратной платформы.
А вот в мире rpm-пакетов различия велики. Во-первых, из-за того, что есть два совершенно независимых дистрибьютера Red Hat и SUSE, для которых совершенно не нужна совместимость. Во-вторых, у этих дистрибьютеров есть дистрибутивы с тех. поддержкой и экспериментальные. Между ними совместимость тоже не нужна. У нас получилось, что для el6, el7 и el8 свои пакеты. Отдельно пакет для Fedora. Пакеты для SLES11 и 12 и отдельный для openSUSE. Основная проблема — в зависимостях и именах пакетов.
Проблема зависимостей
Увы, одни и те же пакеты часто оказываются под разными именами в разных дистрибутивах. Ниже неполный список зависимостей пакета veeam.
| Для EL7: | Для SLES 12: |
|---|---|
|
|
В результате список зависимостей оказывается уникальным для дистрибутива.
Хуже бывает, когда под старым именем пакета начинает прятаться обновлённая версия.
Пример:
В Fedora 24 обновился пакет ncurses c версии 5 до версии 6. Наш продукт собирался именно с 5-той версией, для обеспечения совместимости со старыми дистрибутивами. Чтобы воспользоваться старой 5-той версией библиотеки на Fedora 24, пришлось использовать пакет ncurses-compat-libs.
В результате для Fedora появляется два пакета, с разными зависимостями.
Дальше интереснее. После очередного обновления дистрибутива пакет ncurses-compat-libs с 5-той версией библиотеки оказывается недоступным. Для дистрибьютера накладно тянуть старые библиотеки в новую версию дистрибутива. Спустя некоторое время проблема повторилась и в дистрибутивах SUSE.
В результате для некоторых дистрибутивов пришлось отказаться от явной зависимости от ncurses-libs, а продукт поправить так, чтобы он мог работать с любой версией библиотеки.
Кстати, в 8-й версии Red Hat больше нет мета-пакета python, который ссылался на старый добрый python 2.7. Есть python2 и python3.
Альтернатива пакетным менеджерам
Проблема с зависимостями стара и давно очевидна. Вспомнить хотя бы Dependency hell.
Объединить разнообразные библиотеки и приложения так, чтобы все они стабильно работали и не конфликтовали — собственно, эту задачу и пытается решать любой дистрибьютор Linux.
Совсем иначе пытается решать эту проблему пакетный менеджер Snappy от Canonical. Основная идея: приложение выполняется в изолированной и защищённой от основной системы песочнице. Если приложению нужны библиотеки, то они поставляются вместе с самим приложением.
Flatpak также позволяет запускать приложения в песочнице, используя Linux Containers. Идею песочницы использует и AppImage.
Эти решения позволяют создавать один пакет для любых дистрибутивов. В случае с Flatpak установка и запуск приложения возможна даже без ведома администратора.
Основная проблема в том, что не все приложения могут работать в песочнице. Некоторым нужно прямое обращение к платформе. Я уж не говорю про модули ядра, которые жёстко зависят от ядра и никак не вписываются в концепцию песочницы.
Вторая проблема – популярные в enterprise-среде дистрибутивы от Red Hat и SUSE ещё не содержат поддержку Snappy и Flatpak.
В связи с этим Veeam Agent for Linux нет ни на snapcraft.io ни на flathub.org.
В завершение вопроса о пакетных менеджерах замечу, что есть вариант отказаться вовсе от пакетных менеджеров, объединив в один пакет бинарные файлы и скрипт для их установки.
Такой bundle позволяет создать один общий пакет для разных дистрибутивов и платформ, производить интерактивный процесс установки, осуществляя необходимую кастомизацию. Я сталкивался с такими пакетами для Linux только от VMware.
Проблема обновлений
Даже если все проблемы с зависимостями решены, программа может работать по-разному на одном и том же дистрибутиве. Дело в обновлениях.
Есть 3 стратегии обновления:
- Самая простая – не обновлять никогда. Настроил сервер и забыл. Зачем обновления, если всё работает? Проблемы начинаются при первом же обращении в службу поддержки. Создатель дистрибутива поддерживает только обновлённый релиз.
- Можно довериться дистрибьютеру и настроить автоматическое обновление. В этом случае звонок в службу поддержки вероятен сразу после неудачного обновления.
- Вариант ручного обновления только после его обкатки на тестовой инфраструктуре – самый верный, но дорогой и трудоёмкий. Далеко не все способны его себе позволить.
Так как разные пользователи применяют разные стратегии обновления, то и поддерживать нужно и самый свежий релиз, и все ранее выпущенные. Это усложняет и процесс разработки, и процесс тестирования, добавляет головной боли службе поддержки.
Разнообразие аппаратных платформ
Различные аппаратные платформы – это проблема, в значительной степени специфичная именно для native-кода. Как минимум, приходится собирать бинарники для каждой поддерживаемой платформы.
В проекте Veeam Agent for Linux мы всё никак не можем поддержать хоть что-нибудь такое RISC-овое.
Подробно останавливаться на этом вопросе не буду. Обозначу лишь основные проблемы: платформозависимые типы, такие как
size_t, выравнивание структур и byte order.Статическая и/или динамическая линковка
А вот вопрос «Как линковаться с библиотеками — динамически или статически?» стоит обсудить.
Как правило, С/С++ приложения под Linux используют динамическую линковку. Это отлично работает в том случае, если приложение собрано специально под конкретный дистрибутив.
Если же стоит задача охватить разнообразные дистрибутивы одним бинарным файлом, то приходится ориентироваться на самый старый поддерживаемый дистрибутив. Для нас это Red Hat 6. Он содержит gcc 4.4, который даже стандарт С++11 поддерживает не полностью.
Мы собираем наш проект с помощью gcc 6.3, который полностью поддерживает C++14. Естественно, в таком случае на Red Hat 6 библиотеку libstdc++ и boost приходится тащить с собой. Проще всего линковаться с ними статически.
Но увы, не со всеми библиотеками можно линковаться статически.
Во-первых, системные библиотеки, такие как libfuse, libblkid необходимо линковать динамически, чтобы быть уверенным в совместимости их с ядром и его модулями.
Во-вторых, есть тонкость с лицензиями.
Линцензия GPL в принципе разрешает линковать библиотеки только с opensource кодом. MIT и BSD разрешают статическую линковку и позволяют включать библиотеки в проект. А вот LGPL вроде как не противоречит статической линковке, но требует предоставить в общий доступ файлы, необходимые для связывания.
В общем случае использование динамической линковки обезопасит от необходимости что-то предоставлять.
Сборка С/С++ приложений
Для сборки С/С++ приложений для разных платформ и дистрибутивов достаточно подобрать или собрать gcc подходящей версии и воспользоваться кросс-компиляторами для специфичных архитектур, собрать весь набор библиотек. Работа эта вполне реализуемая, но довольно хлопотная. И нет никаких гарантий, что выбранный компилятор и библиотеки обеспечат работоспособный вариант.
Очевидный плюс: сильно упрощается инфраструктура, так как весь процесс сборки можно выполнить на одной машине. Кроме того, достаточно собрать один набор бинарных файлов для одной архитектуры и можно паковать их в пакеты для разных дистрибутивов. Именно так собираются пакеты veeam для Veeam Agent for Linux.
В противовес этому варианту можно просто подготовить build ферму, то есть несколько машин для сборки. Каждая такая машина будет обеспечивать компиляцию приложения и сборку пакета для конкретного дистрибутива и определённой архитектуры. В таком случае компиляция производится теми средствами, которые подготовил дистрибьютер. То есть этап подготовки компилятора и подбор библиотек отпадает. Кроме того, процесс сборки может быть легко распараллелен.
Есть, правда, и минус у такого подхода: для каждого дистрибутива в рамках одной архитектуры придётся собирать свой набор бинарных файлов. Также минусом является то, что такое множество машин нужно обслуживать, выделять большое количество дискового пространства и оперативной памяти.
Таким образом собираются KMOD пакеты модуля ядра veeamsnap под дистрибутивы Red Hat.
Open Build Service
Коллеги из SUSE попробовали реализовать некоторую золотую середину в виде специального сервиса для компиляции приложений и сборки пакетов — openbuildservice.
По сути, это гипервизор, который создаёт виртуальную машину, устанавливает в ней все необходимые пакеты, выполняет компиляцию приложения и сборку пакета в этой изолированной среде, после чего такая виртуальная машина освобождается.
Реализованный в OpenBuildService планировщик сам определит, сколько виртуальных машин он может запустить для оптимальной скорости сборки пакетов. Встроенный механизм подписи сам подпишет пакеты и выложит их на встроенный репозиторий. Встроенная система версионного контроля сохранит историю изменений и сборок. Остаётся просто добавить в эту систему свои исходники. Даже сервер самому поднимать не обязательно, а можно воспользоваться открытым.
Тут, правда, есть проблема: такой комбайн трудно вписывается в существующую инфраструктуру. Например, версионный контроль не нужен, у нас уже есть свой для исходников. Механизм подписи у нас отличается: используется специальный сервер. Репозиторий тоже не нужен.
Кроме того, поддержка других дистрибутивов — к примеру, Red Hat — реализована довольно скудно, что вполне объяснимо.
Достоинством такого сервиса является быстрая поддержка очередной версии дистрибутива SUSE. До официального объявления о релизе необходимые для сборки пакеты выкладываются на публичный репозиторий. В списке доступных дистрибутивов на OpenBuildService появляется новый. Выставляем галочку, и он добавляется в план сборки. Таким образом, добавление новой версии дистрибутива выполняется практически в один клик.
В нашей инфраструктуре с использованием OpenBuildService собирается всё многообразие KMP пакетов модуля ядра veeamsnap для дистрибутивов SUSE.
Далее я хотел бы остановиться на вопросах, специфичных именно для модулей ядра.
kernel ABI
Модули ядра Linux исторически распространялись в виде исходных текстов. Дело в том, что создатели ядра не обременяют себя заботой о поддержке стабильного API для модулей ядра, а тем более на бинарном уровне, далее kABI.
Чтобы собрать модуль для ванильного ядра, обязательно нужны header-ы именно этого ядра, и работать он будет только на этом ядре.
DKMS позволяет автоматизировать процесс сборки модулей при обновлении ядра. В результате пользователи репозитория Debian (и его многочисленных родственников) используют модули ядра либо из репозитория дистрибьютера, либо собираемые из исходников с помощью DKMS.
Однако такая ситуация не особо устраивает Enterprise-сегмент. Распространители проприетарного кода хотят распространять продукт в виде собранных бинарников.
Администраторы не хотят держать средства разработки на production-серверах из соображений безопасности. Дистрибьютеры Enterprise Linux — такие, как Red Hat и SUSE — решили, что для своих пользователей стабильное kABI они смогут поддержать. В результате появились KMOD пакеты для Red Hat и KMP пакеты для SUSE.
Суть такого решения довольно проста. Для конкретной версии дистрибутива API ядра freeze-ится. Дистрибьютор заявляет, что он использует именно ядро, например, 3.10, и вносит только исправления и улучшения, которые никак не затрагивают интерфейсы ядра, а собранные для самого первого ядра модули могут быть использованы для всех последующих без перекомпиляции.
Red Hat заявляют о kABI совместимости для дистрибутива на протяжении всего жизненного цикла. То есть собранный модуль для rhel 6.0 (релиз ноября 2010) должен также работать и на версии 6.10 (релиз июня 2018). А это почти 8 лет. Естественно, задача это довольно сложная.
Мы зафиксировали несколько случаев, когда из-за проблем с kABI совместимостью модуль veeamsnap переставал работать.
После того, как модуль veeamsnap, собранный для RHEL 7.0, оказался несовместим с ядром из RHEL 7.5, но при этом загружался и гарантированно ронял сервер, мы отказались от использования kABI совместимости для RHEL 7 вообще.
В настоящий момент KMOD пакет для RHEL 7 содержит сборку для каждой версии релиза и скрипт, который обеспечивает загрузку модуля.
SUSE к задаче kABI совместимости подошли более осторожно. Они обеспечивают kABI совместимость только в рамках одного service pack.
Например, релиз SLES 12 состоялся в сентябре 2014. А SLES 12 SP1 уже в декабре 2015, то есть прошло чуть больше года. Несмотря на то, что оба релиза используют ядро 3.12, они kABI несовместимы. Очевидно, что поддерживать kABI совместимость в течение всего лишь года значительно проще. Годовой цикл обновления модуля ядра не должен вызывать проблем у создателей модулей.
В результате такой политики SUSE мы не зафиксировали ни одной проблемы с kABI совместимостью у нашего модуля veeamsnap. Правда, и число пакетов для SUSE почти на порядок больше.
Патчи и бэкпорты
Несмотря на то, что дистрибьютеры стараются обеспечить kABI совместимость и стабильность ядра, они ещё и стараются улучшить производительность и устранить дефекты этого стабильного ядра.
При этом кроме собственной «работы над ошибками» разработчики ядра enterprise linux отслеживают изменения в ванильном ядре и переносят их в своё «стабильное».
Иногда это приводит к новым ошибкам.
В последнем релизе Red Hat 6 в одном из минорных обновлений была допущена ошибка. Она приводила к тому, что модуль veeamsnap гарантированно валил систему при освобождении снапшота. Сравнив исходники ядра до и после обновления, мы выяснили, что виной всему был backport. Аналогичный фикс был произведён в ванильном ядре версии 4.19. Вот только в ванильном ядре этот фикс работал нормально, а при переносе его в «стабильное» 2.6.32 возникла проблема со спин-блокировкой.
Конечно, ошибки встречаются у всех и всегда, но стоило ли тащить код из 4.19 в 2.6.32, рискуя стабильностью?.. Я не уверен…
Хуже всего, когда к перетягиванию каната «стабильность»<->«модернизация» подключается маркетинг. Отделу маркетинга нужно, чтобы ядро обновлённого дистрибутива был стабильным, с одной стороны, и в тоже время было лучше по производительности и имело новые функции. Это приводит к странным компромиссам.
Когда я попробовал собрать модуль на ядре 4.4 от SLES 12 SP3, я с удивлением обнаружил в нём функционал из ванильного 4.8. На мой взгляд, реализация блочного ввода/вывода ядра 4.4 от SLES 12 SP3 больше походит на ядро 4.8, чем на предыдущий релиз стабильного 4.4 ядра от SLES12 SP2. Каков был процент перенесённого кода из ядра 4.8 в SLES-овский 4.4 для SP3 я судить не берусь, однако назвать ядро всё тем же стабильным 4.4 у меня язык не поворачивается.
Самое неприятное в этом то, что при написании модуля, который бы одинаково хорошо работал на разных ядрах, более нельзя опираться на версию ядра. Приходится ещё и учитывать дистрибутив. Хорошо, что иногда можно завязаться на дефайн, который появляется вместе с новым функционалом, однако такая возможность появляется не всегда.
В результате код обрастает причудливыми директивами условной компиляции.
Встречаются ещё и патчи, которые меняют задокументированное API ядра.
Наткнулся на дистрибутив KDE neon 5.16 и был очень удивлён, увидев что вызов lookup_bdev в этой версии ядра изменил перечень входных параметров.
Чтобы собраться, пришлось в makefile добавлять скрипт, который проверяет, есть ли параметр mask у функции lookup_bdev.
Подпись модулей ядра
Но вернёмся к вопросу распространения пакетов.
Одно из достоинств стабильного kABI в том, что модули ядра в виде бинарного файла можно подписать. В этом случае разработчик может быть уверен, что модуль не был случайно повреждён или намеренно изменён. Проверить это можно командой modinfo.
Дистрибутивы Red Hat и SUSE позволяют проверять подпись модуля и загружать его, только если в системе зарегистрирован соответствующий сертификат. Сертификат представляет собой публичный ключ, которым подписывается модуль. Мы распространяем его в виде отдельного пакета.
Проблема тут в том, что сертификаты могут быть либо встроенные в ядро (их используют дистрибьютеры), либо должны быть записаны в энергонезависимую память EFI с помощью утилиты mokutil. Утилита mokutil при установке сертификата требует перезагрузить систему и ещё до загрузки ядра операционной системы предлагает администратору разрешить загрузку нового сертификата.
Таким образом, добавление сертификата требует физического доступа администратора к системе. Если машина располагается где-то в облаке либо просто в удалённой серверной и доступ есть только по сети (например, по ssh), то добавить сертификат будет невозможно.
EFI на виртуальных машинах
Несмотря на то, что уже давно EFI поддерживается практически всеми создателями материнских плат, при установке системы администратор может не задуматься о необходимости EFI, и он может быть отключён.
Не все гипервизоры поддерживают EFI. VMWare vSphere поддерживает EFI, начиная с версии 5.
Microsoft Hyper-V также получил поддержку EFI, начиная с Hyper-V for Windows Server 2012R2.
Однако в дефолтной конфигурации этот функционал для Linux машин выключен, а значит, сертификат установить нельзя.
В vSphere 6.5 выставить опцию Secure Boot можно только в старой версии веб-интерфейса, который работает через Flash. Web UI на HTML-5 пока сильно отстаёт.
Экспериментальные дистрибутивы
Ну и напоследок рассмотрим вопрос экспериментальных дистрибутивов и дистрибутивов без официальной поддержки. С одной стороны, такие дистрибутивы навряд ли встретишь на серверах серьёзных организаций. Официальной поддержки у таких дистрибутивов нет. Поэтому и обеспечивать тех. поддержку продукта на таком дистрибутиве нельзя.
Однако такие дистрибутивы становятся удобной площадкой для пробы новых экспериментальных решений. Например, Fedora, OpenSUSE Tumbleweed или Unstable версии Debian. Они довольно стабильны. В них всегда новые версии программ и всегда новое ядро. Через год этот экспериментальный функционал может оказаться в обновлённом RHEL, SLES или Ubuntu.
Так что если что-то не работает на экспериментальном дистрибутиве — это повод разобраться в проблеме и решить её. Нужно быть готовым к тому, что этот функционал скоро появится на production-серверах пользователей.
Существующий на текущий момент список официально поддерживаемых дистрибутивов для версии 3.0 вы можете изучить здесь. Но реальный список дистрибутивов, на которых наш продукт способен работать, намного шире.
Лично мне был интересен эксперимент с ОС «Эльбрус». После доработки пакета veeam наш продукт установился и заработал. Про этот эксперимент я писал на Хабре в статье.
Ну а поддержка новых дистрибутивов продолжается. Ожидаем появления на свет версии 4.0. Вот-вот должна появиться бэта, так что следите за whats-new!
Комментарии (100)
saag
14.10.2019 14:11+1я пробовал накатить Genymotion 3, который под Ubuntu 18.04, на Ubuntu 16.04, встать то он встал, но не заработал…
Londoner
14.10.2019 16:39Мне кажется, надо как-то придумать, как ограничить количество дистрибутивов линукса. Силы сообщества распыляются на пиление десятка, если не сотни болгеносов, вместо того, чтоб взять один дистрибутив и сделать так, чтоб там всё работало из коробки, тогда им будут пользоваться не на 0.0001% проценте дескптопов.
0xd34df00d
14.10.2019 17:11Не надо, пожалуйста. В этом разнообразии вся прелесть — мне удобно под гентой, и я сижу под гентой, а не под одним дистром для одного народа.
Ну и как автору пары ненужных опенсорс-софтин, в которые я вбухал ну очень много времени (хотя мог бы более популярные аналоги пилить), всегда интересно читать про идеи таких ограничений.
CodeImp Автор
14.10.2019 17:14+1Прям призыв в очередному holywar-у! Придумывать ничего не надо. Есть люди (или их объединения, иногда коммерческие), которые зарабатывают деньги на поддержке своего дистрибутива. Работа эта сложная, и не всегда окупается, потому реально живых дистрибутивов не так-то и много. Ну и потом, некоторое разнообразие всё равно нужно. К примеру в Германии предпочитают SUSE, в США — Red Hat. В последнее время хорошо поднялась Ubuntu, подвинув конкурентов. Они деньги на поддержке зарабатывают, а потому и вкладывают в развитие. Реально на фанатах держится может только Arch, но это явно не ширпотреб.
Londoner
15.10.2019 12:24+1Есть люди (или их объединения, иногда коммерческие), которые зарабатывают деньги на поддержке своего дистрибутива.
Вот это — очень плохой конфликт интересов. Ибо чем лучше ты делаешь свой дистрибутив, тем меньше требуется поддержки, тем меньше ты зарабатываешь. Не понятно, как это исправить, разве что внести в GPL запрет на взымание денег за техподдержку…CodeImp Автор
15.10.2019 12:38+1Поверьте, проблем и так достаточно, так что сознательно их никто не делает, ну мне так кажется, по крайней мере для Linux.
Техподдержка нужна для организаций, бизнес которых зависит от этого ПО. И лицензия — типа страховка, чтобы в случае чего обратиться, чтобы «тебе сделали чтоб работало».
Альтернативный есть вариант — набирать и оплачивать штат специальстов, чтоб поддерживали твоё ПО. Этот вариант как правило выходит дороже.
Если продукт работает плохо, требуется большой штат тех.поддержки, программистов на поддержке, а это затраты. Так что делать плохо не выгодно никому, так что все вроде как стараются сделать хорошо, но не у всех получается.
gecube
15.10.2019 12:40Конфликт неявный. Чем больше пользуются бесплатным — тем большее количество пользователей привыкнет и захочет перейти на платный. Другой вопрос, что, да, делать бесплатную версию идеальной стимула не будет. Сносной — да. Лучше, чем у конкурентов — да. Но безглючный и идеальной — нет
x67
15.10.2019 14:01+1Это как?
Free:
Basic features
Community support
Bugs included!
Pro:
All features full support
No.bugs
Если продукт один и тот же, крайне накладно исправлять баги лишь в про версии. Поэтому у команды цель всегда сделать хорошо. Другое дело, что если платная версия отличается не только поддержкой, но и функционалом, проблемы с платным функционалом будут решаться быстрее, что логично
Ну и в целом, если продукт получился не очень прибыльным и популярным, сложно расчитывать на высокую замотивированность. Хотя тут есть обратная зависимость — качество продукта влияет на его популярностьgecube
15.10.2019 14:06Действительно в Free баги будут. Хотя бы потому что — пользователи free — широкое поле для экспериментов, именно они будут получать первые нестабильные фичи и возможности, на них же они будут обкатываться. Потом после стабилизации — эти фичи и багфиксы перекочевывают в Pro-версию.
Либо в Pro версии может быть расширенный пакет опций: какие-то возможности, которые в бесплатной версии отсутствуют.
> проблемы с платным функционалом будут решаться быстрее, что логично
Вопрос приоритизации тасков, да.
Londoner
14.10.2019 21:42+1Так, ну и зачем это минусовать, да ещё и гадить в карму? Спокойно дискутировать на Хабре больше не принято?
slonopotamus
15.10.2019 08:43+1Потому что люди, которые пытаются указывать другим как им надо жить, мало кому нравятся.
Londoner
15.10.2019 10:37Да, если Вы живёте в социуме, есть куча правил, писаных и неписаных, указывающих, как Вам жить, обычно для Вашего же блага и блага окружающих. От уголовного кодекса и ПДД до GPLv3 и правил поведения за столом. Срочно включаем истерику и бежим
затыкать мне ротгадить в карму?slonopotamus
15.10.2019 14:461. Наличие подобных правил ещё не повод увеличивать их количество.
2. Где вы увидели истерику?Londoner
15.10.2019 15:481. Конечно не повод. Уж извините за капитанские истины, но правила появляются для увеличения всеобщего блага, предотвращения жертв, материального ущерба и иных нежелательных последствий. И да, по мере развития человечества их становится всё больше, например в 19 веке ПДД (в нынешнем виде) не существовало, а сотни лет назад можно было рабов держать. А ещё бывают несправедливые правила, и вот с ними нужно бороться.
2. Истерики вижу регулярно в моём профиле, в разделе «карма», уж не знаю, Ваши или чьи-то ещё.
Fenzales
15.10.2019 15:36Всё-таки есть разница между тем, что ограничивается уголовным кодексом, и ограничением возможности написать свой дистрибутив, не находите?
Я бы вот не хотел, чтобы ко мне применялись какие-то санкции за сборку ISO-образа из LFS.Londoner
15.10.2019 15:56Ну, есть уголовный кодекс, а есть правила поведения за столом, на нарушения санкции разные. И да, наверное, не должно быть санкций за сборку ISO-образа из LFS. Но нужно чтобы до каждого дошло, что если хочешь помочь линуксу, не стоит пилить n+1-ый дистрибутив, а лучше поучаствовать в улучшении самого популярного. И да, желающих участвовать нужно ценить, а не бить по рукам. Как-то так, нет?
Кстати, как вариант, хотелось бы, чтоб был способ сбора статистики/метрик, сколько инсталяций по каждому дистрибутиву. И довольны ли пользователи и сколько раз день в этом дистрибутиве в среднем чего-то крашится, как быстро фиксятся баги (а не просто закрываются баг-репорты). Сразу станет ясно, чем стоит пользоваться и что стоит развивать, а что, увы, не стоит.Fenzales
15.10.2019 16:22если хочешь помочь линуксу, не стоит пилить n+1-ый дистрибутив, а лучше поучаствовать в улучшении самого популярного
Лучше только для пользователей самого популярного дистрибутива, нужды-то у всех разные.
Кстати, как вариант, хотелось бы, чтоб был способ сбора статистики
Телеметрия на уровне ядра? :)скольку есть инсталяций по каждому дистрибутиву
И так очевидно лидерство Ubuntu и Debian. Во втором, кстати, произошел раскол как раз из-за желания прийти к единому стандарту в виде Systemd.И сколько раз в этом дистрибутиве чего-то крашится.
Очевидно лидерство либо SUSE, либо RHEL, за поддержку которых нужно платить.Londoner
15.10.2019 21:11Лучше только для пользователей самого популярного дистрибутива, нужды-то у всех разные.
1. Да, нужды у пользователей Windows тоже разные, но даже у Майкрософта не хватило ресурсов тащить Windows NT и Windows 95/8. Задумайтесь.
2. Что мешает сделать дистрибутив, максимально учитывающий нужды всех?
Телеметрия на уровне ядра? :)
Зачем именно на уровне ядра? И можно не телеметрию, а считать число скачиваний iso-образов, если паранойя зашкаливает даже для благого дела.
И так очевидно лидерство Ubuntu и Debian.
А я вот думаю, что Минт, ибо Убунта в последние годы разваливается на глазах, а в Дебиане из коробки очень мало чего работает.
Во втором, кстати, произошел раскол сообщества как раз из-за желания некоторых разработчиков пропихнуть единый стандарт в виде Systemd.
Да-да, давайте вместо того, чтоб учиться договариваться, запилим ещё один дистрибутив, ага…
И сколько раз в этом дистрибутиве чего-то крашится.
Очевидно лидерство либо SUSE, либо RHEL, за поддержку которых нужно платить.
В смысле, SUSE и RHEL крашатся больше, чем другие дистрибутивы или меньше?gecube
15.10.2019 23:37В смысле, SUSE и RHEL крашатся больше, чем другие дистрибутивы или меньше?
Я тоже не понял, что коллега имел в виду.
Fenzales
16.10.2019 11:26+11. Да, нужды у пользователей Windows тоже разные, но даже у Майкрософта не хватило ресурсов тащить Windows NT и Windows 95/8. Задумайтесь.
Windows — не свободное ПО, майкрософтовские разработчики не могут разрабатывать что душе угодно.
2. Что мешает сделать дистрибутив, максимально учитывающий нужды всех?
То же, что мешает всем быть здоровыми и богатыми :) Ну то есть вот пример — SUSE не нравился NetworkManager, они написали Wicked — дебиановские мейнтейнеры бы его в апстрим, вероятно, не пропустили бы из-за завязки на YaST. Что делать?
В конце концов, кто-то может реже обновлять свой софт в соответствии, например, с версиями Glibc — им не подходит Rolling Release, кому-то наоборот нужны bleeding-edge версии библиотек, кому-то нужна определенная система инициализации, потому что у него весь софт на неё завязан, кто-то не может перейти на Wayland, и так далее, и тому подобное.
Да-да, давайте вместо того, чтоб учиться договариваться, запилим ещё один дистрибутив, ага…
Там долго пытались договориться, было два голосования, разделившие голосующих пополам.В смысле, SUSE и RHEL крашатся больше, чем другие дистрибутивы или меньше?
Меньше.
embden
15.10.2019 13:54+1Проблема ведь в том, что люди не пилят очередной дистрибутив, чтобы сделать его лучше для других, они пилят очередной дистрибутив, потому что хочется, потому что обида на другого майнтейнера, потому что хочется быть значимым, потому что в другом месте не хотят инноваций. То есть, если Вы хотите решить проблему многообразия дистрибутивов, Вам надо взять существующий и поменять инфраструктуру разработки так, чтобы она решала психологические проблемы людей.
Тоже самое и с открытыми приложениями. Создаётся куча разного ненужного всего. То есть даже векторных редакторов существует несколько. А я взял буквально вчера Inkscape, нарисовал кривую, применил модифайер Mirror, Inkscape упал. И это топовый векторный редактор. Хотите, чтобы разработчики других векторных редакторов помогли Inkscape и не распылялись на другое? Создайте инфраструктуру, которая бы решала их психологические проблемы в рамках существующих решений.Londoner
16.10.2019 00:27+1Ну давайте думать в эту сторону. Мне кажется, быть контрибьютером Debian или Ubuntu — это круче, чем быть основателем JustAnother Linux, или я не прав?
gecube
16.10.2019 00:31Не факт. Тут сталкиваются амбиции и несовместимые характеры людей из опенсорца. Как же так — если ты контрибьютор, то ты играешь по ЧУЖИМ правилам. А в своем JustAnotherLinux — ты и есть царь и Бог.
embden
16.10.2019 02:49Я, к примеру, тоже хочу создать свой desktop environment. Потихоньку работаю в этом направлении.
Я пытался примкнуть к другим операционным системам и DE — не получилось. У кого-то другие цели, у кого-то целей вообще нет. Мои идеи никогда не будут приняты сообществом — они довольно странные. Поэтому у меня просто нет другого выхода, как медленно (очень медленно) работать над своим.
gecube
16.10.2019 00:33Мне кажется, что лучше вложиться в разработку нормальных инструментов. Поглядите — вот коллеги выше по треду пишут, что правильно собрать deb/rpm пакет — это сложная задача. Это так. Получается, не хватает фреймворков, которые взяли бы задачу опакечивания и проверки этого пакета в различных окружениях с разработчика на себя. Сусевский OBS, как мне кажется, максимально близок к решению, но опять же минус, что у него фокус только на Сусе.
ip1981
14.10.2019 18:20+1Nix? (Тот, который пакетный менеджер. Можно и в тарболл запихать, и докер. Ядро остаётся за кадром, но пока Линус с нами, проблем не будет.
CodeImp Автор
14.10.2019 18:28+1Божеш-мой. Ещё и nix. Ох уж эта вариативность…
«Ядро за кадром» — ну для большинства аппликух конечно можно его оставить за бортом.
«Линус с нами, проблем не будет» — проблемы будут всегда, больше или меньше. Я думаю, пока у ядра есть коммерческое применение — над ним будут работать. Большая удача, что оно появилось на значительной доле смартфонов, которые продают с предустановленным ядром. Я помню как работал Linux 15 лет назад… Это была боль.
develop7
14.10.2019 20:59+1Ещё и nix
не ещё, просто nix. вместо всего вот этого вот. см. для примера https://daedaluswallet.io/#download
batment
14.10.2019 18:28Мне очень нравится подход приложений, написанных на Go, например Terraform: скачал один бинарник, который работает везде в рамках выбранной архитектуры и ни о чем париться не нужно, обновляешь только когда сам захочешь.
gecube
14.10.2019 19:02+3Ага, только если там завязка на системные библиотеки (типа работы с lvm), то, сорян, все равно работать не будет. Я этого хапнул со skopeo. Его приходится компилить в бинарь под каждый дистриб отдельно ((((
eumorozov
14.10.2019 18:44Простите, а зачем поддерживать аж Red Hat 6?.. Этот дистрибутив вышел в 1999 году — 20 лет назад. Даже в музеях он вряд ли используется. Debian 6 вышел в 2011 — тоже эпоха по компьютерным меркам. И тоже вряд ли используется хоть где-либо.
CodeImp Автор
14.10.2019 18:57+2Ну Debian 6 не поддерживается его создателями, так что и мы в следующей версии откажемся от её официальной поддержки. А вот Red Hat 6.0 всё ещё жив и поддерживается, и наши пользователи не обрадуются, если мы его зарежем.
Enterprise пользователи очень не любят кардинально менять свою инфраструктуру. Это десктопы и ноуты живут лет по 5-7, а серваки живут десятилетиями. Им меняют процессоры, накопители, но система с данными продолжает жить.
0xd34df00d
14.10.2019 19:27+1Это разные дистрибутивы. Тут речь, скорее всего, о RHEL 6, который вышел таки чуть позже.
CodeImp Автор
14.10.2019 19:34Так точно, RHEL 6, который с ядром 2.6.32, а не RHL 6 с ядром 2.2.5 (страшно даже представить).
alhimik45
14.10.2019 21:09+1Насчет kABI: а нет возможности делать отдельно бинарь, а в DKMS модуль тоненькую прослоечку для его общения с ядром?
screwer
15.10.2019 07:50В эту "прослоечку" придется завернуть вообще всё, включая доступ к полям структур ядра, которые могут "съехать" (и обязательно "съедут") от одних только опций конфига сборки ядра, даже в пределах абсолютно той же версии. Именно поэтому в линуксе нужны kernel headers точно под установленное ядро и сборка драйверов из исходников. Даже костыль прикручен, в виде хеша от версии и опций конфига — modins откажется грузить драйвер собранный из чуть другого набора, даже если с ним по-факту нет проблем.
CodeImp Автор
15.10.2019 09:27+1На счёт модулей я бы сказал так: чем он проще и примитивнее, тем лучше. Если есть возможность переложить что-то на user space код, то это нужно делать.
Но увлекаться тут тоже нельзя, так как если для обработки каждого события из модуля дёргать обработчик в user space, то сильно просядет performance.
В общем драйвера — это отдельная область программирования с кучей ограничений, если сравнивать с user space.
anikavoi
14.10.2019 21:17+3В мире deb-пакетов уровень совместимости поразителен. Один и тот же пакет одинаково хорошо ставится и работает как на Debian 6, так и на Ubuntu 19.04.
ДА ЛАДНО?! :)
Риалли?CodeImp Автор
15.10.2019 08:57+1Ну именно для Veeam Agent for Linux для всех дистрибутивов с dpkg один пакет veeam под каждую платформу (i386 и amd64) и один пакет veeamsnap (общий, так как в сорцах). Всплыли проблемы с поддержкой именно Debian 10 в скриптах запуска сервиса, но в бэте мы это уже поправили. А пока версия 3.0 не ставится нормально только на Debian 10.
esata
14.10.2019 22:02TLDR: используйте snap или appimage
gecube
15.10.2019 09:36Не надо ни то, ни то.
Со snap'ом я говна поел, когда приходит разработчик, он там чего-то в docker'е запускает, но не взлетает. Оказывается он поставил его через snap и там своя отдельная песочница с ограничением прав. Приходится переустанавливать «как надо».
Т.е. — snap вероятно (как концепция, а не реализация!) хорош для прикладных вещей типа браузера, среды разработки, блокнота, мп3-плейера и пр. Но не для каких-то системных вещей.
Sabubu
15.10.2019 00:48+1Проблема описана очень правильная. Линукс не очень-то дружелюбен к стороннему софту, особенно если он закрыт. Предполагается, что пользователь должен либо ограничиться пакетами из репозитория, а если их там нет, либо сам собирать (если он открытый) или подгонять костыли (если он закрытый) под нужный софт (а может, и поддерживать), либо обходиться без него.
Это, на мой взгляд, бесперспективный подход. Поддержка пакетов и патчей к ним в каждом отдельном дистрибутиве — тяжелый труд. Гораздо оптимальнее было бы прийти к какому-то общему API, общей платформе. Пусть даже это будет не одно API, а набор, чтобы цвели все цветы и чтобы у нас был выбор из 3 библиотек для воспроизведения звука и 5 библиотек для работы с USB устройствами — это будет лучше, чем то, что сейчас.
Потому что сейчас фактически единственное API — это API ядра Линукса. Сравните с Windows, где есть куча стандартных библиотек и функций на все случаи жизни с документацией в MSDN.
Я знаю про Snap, Flatpak, AppImage, nix и что там еще есть. AppImage — это не решение, у него проблемы со временем запуска и он не дает никаких API, а лишь формат упаковки файлов. Snapcraft/Flatpack — это уже что-то более рабочее.
Ну и конечно, надо лучше защищать данные от приложений. Сравните Android, где есть куча разрешений, и какую-нибудь Убунту, где проприетарное приложение с пользовательскими правами легко и спокойно читает все железные идентификаторы оборудования, MAC адреса, список окружающих вайфай точек (определяя ваше точное положение), историю, куки и сохраненные пароли вашего браузера и сохраняет их на свой сервер (а вы думали, бесплатный сыр существует?). Линукс (популярные дистрибутивы) в сравнении с Андроид или iPhone — это кошмар с точки зрения защиты данных пользователя.
DoctorMoriarty
15.10.2019 02:51>проприетарное приложение с пользовательскими правами легко и спокойно читает все железные идентификаторы оборудования, MAC адреса, список окружающих вайфай точек (определяя ваше точное положение), историю, куки и сохраненные пароли вашего браузера и сохраняет их на свой сервер
Было бы неплохо указать в таком комментарии название приложения, которое крадёт пароли пользователя (именно крадёт, а не сохраняет их на сервер с согласия пользователя в рамках функционала, заявленного для этого приложения). Приложив пруфы. Дабы пользователи знали, каким приложением пользоваться опасно.
Иначе это напоминает излюбленные завсегдатаями опеннета рассуждения про «зонды».
slonopotamus
15.10.2019 08:49это будет лучше
Лучше кому? Авторам проприетарных приложений? Так вы же сами дальше пишете что они зло, крадут пароли и всё такое :)
gecube
15.10.2019 09:40Система безопасности на Андроиде помойка. Аргументирую. Вот ставите Вы какое-то приложение из маркета. И разработчик, чтобы не париться, тупо накидывает туда ВСЕ возможные разрешения, которые в принципе ему могут понадобиться (или не понадобиться). Ваш выбор — согласиться с ним, или нет.
Возможно сейчас стало лучше и можно на установленное приложение отзывать часть разрешений. Возможно гугль начал более серьезно подходить к аудиту приложений, чтобы разработчики не просили привилегий больше, чем им реально нужно. Но факт в том, что в истории был момент, о котором я пишу. Что сложная система привилегий приводит к тому, что ее все игнорируют. Кстати. В Винде та же самая история. Вспомните — сколько было приложений, которые требуют «Администратора», хотя по факту им достаточно разрешения на одно определенное действие.
Я уж не говорю о том, что все эти системы обычно очень грубо классифицируют все возможные действия приложения по категориям (типа «доступ к сети», «доступ к файлам», «работа с GUI», «чтение меток оборудования» и пр.), а иногда нужно чуточку более точная настройка (типа «этому приложению можно открывать только сетевой порт с номером ХХХХ»). Но лучше хоть какие-то механизмы ограничения, чем их полное отсутствие — это тоже факт.Sabubu
15.10.2019 17:55Тем не менее эти разрешения там есть, а в неофициальных сборках Андроид есть способы их отбирать или подсовывать фейковые данные вместо настоящих. В популярных дистрибутивах Линукса этого нет.
gecube
15.10.2019 18:25В популярных дистрибутивах есть selinux и apparmor, но это не совсем то, что Вы имеете в виду. И, да, из тоже надо настраивать (
eumorozov
15.10.2019 19:54+1Увы. Я когда-то, когда у меня было время и полные штаны идеализма, решил включить и полностью настроить на своей системе AppArmor. Чтобы всякая там пропиетарщина, такая как Скайп, например, не лезла, куда не положено.
По-моему, я сдался где-то на втором или третьем приложении. Затратив на это наверное 3-5 дней. И понял, что такая попытка заката солнца вручную просто никогда не взлетит.
Единственный способ для обычного использования в своей системе разграничить приложения — или запускать их исключительно в виртуалках (долго, ресурсоемко, неудобно), или иметь разные устройства для разных нужд (например, отдельный ноутбук исключительно для интернет-банкинга).
zirix
15.10.2019 22:25Есть еще контейнеры, можно туда софт ставить.
Вот обертка для podman. Интерфейс заточен под установку обычных программ в контейнер (настраивает звук, gui, создает ярлык и т.п). Не продакшн реди, но для экспериментов годится.
gecube
15.10.2019 23:38Можно в докерах запускать. Отчасти решает проблему.
Насчет сложности настройки селинукс и аппармор — да, согласен. Но это и беда того, что нет нормальных дефолтных политик, поставляемых вместе с приложением. К сожалению, здесь работает только жесткая диктатура — пока разрабов не будешь заставлять делать продукт от А до Я, то будет эта халява и все будет расползаться, т.к. будут находиться те, кто не играет по правилам и чхать хотел на эти нормативы.
Sabubu
15.10.2019 23:53+1Я просто запускаю скайп из-под отдельного пользователя, в своем отдельном каталоге. Чуть-чуть пришлось заморочиться с предоставлением ему доступа к иксам (к счастью, это делается одним вызовом xhost, не знаю, как будет в вейленде), и к pulseaudio (не стал заморачиваться и дал доступ всем локальным пользователям через TCP порт). Еще хотел дать ограниченный доступ к DBUS, чтобы он мог показывать уведомления, но не мог получать список wifi и bluetooth устройств, но не успел, там надо патчить прокси для dbus, а для этого его надо сначала отрефакторить, так как код там нечитабельный, а у меня руки пока не дошли.
gecube
16.10.2019 00:29Мой коллега из СПб (админ до мозга костей) сендбоксил скайп еще в далеком 2013:
aminux.wordpress.com/2013/06/12/skype-4-2-selinux-sandbox
Трудоемко. Кто бы опакетил подобный способ и сделал его более доступным для народа? Хотя, наверное, это уже не нужно, т.к. скайп прекрасно работает из браузера под Линем.Sabubu
16.10.2019 01:26+1Если в браузере, то надо запускать в приватном режиме, а то эта зараза может кук наставить и отслеживать посещения других страниц с привязкой к логину, email и телефону, если он у вас указан.
CodeImp Автор
16.10.2019 09:54Виртуалка конечно хорошо разграничит приложения, но есть и Docker, вроде как Snappy и Flatpak решают задачу разграничения приложений, запуская их в песочнице?
Сам я этот вопрос не копал глубоко.eumorozov
16.10.2019 10:06+1Задача стоит в том, чтобы приложением можно было пользоваться, например, чтобы из Скайпа можно было отправлять свои файлы и получать их, проигрывать звуки, и т.п., но чтобы приложение не могло получить доступ к файлам и прочим объектам, которые ему не нужны (системные файлы, файлы за пределами определенных каталогов, определенные устройства, системная информация).
Snappy и Flatpak неполное решение, насколько я понимаю. Docker… не знаю. Во-первых, никогда не пытался использовать GUI приложение в Docker, и не уверен, что это возможно. Во-вторых, скорее всего придется пробрасывать кучу всего в Docker, создавая возможность для атаки. Например, если пробросить домашний каталог, то зловред может записать какой-нибудь зловредный код в
~/.bashrc. Если пробросить какие-нибудь устройства, нужные для X приложений, возможно, это даст возможность прослушивать события клавиатуры и делать снимки экрана.
Это я чисто теоретически рассуждаю. Например, многие даже не GUI конфигурации в Docker требуют доступа к сокету Docker'а, а это равнозначно полному доступу к хост-системе.
C AppArmor и приложениями типа Скайпа было такое, что ему нужен доступ просто к невероятному количеству различных файлов, устройств, и т.п. Если запретить некоторые, то он либо работает некорректно, либо падает. Сначала тратишь много часов на то, чтобы определить и дать доступ ко всему, что ему нужно. Потом смотришь на получившуюся конфигурацию и понимаешь, что если было бы желание, то доступ есть уже к такому количеству возможностей, что наверняка при желании можно провести атаку и из под AppArmor.
gecube
16.10.2019 10:28Во-первых, никогда не пытался использовать GUI приложение в Docker, и не уверен, что это возможно.
Это возможно. Я не скажу, что это БЕСПРОБЛЕМНО. Но завести можно при определенной сноровке.
Это я чисто теоретически рассуждаю. Например, многие даже не GUI конфигурации в Docker требуют доступа к сокету Docker'а, а это равнозначно полному доступу к хост-системе.
Именно так.
Aldrog
15.10.2019 14:30Потому что сейчас фактически единственное API — это API ядра Линукса.
Я бы сказал, сейчас де-факто стандартная платформа кроме этого включает PulseAudio и systemd как минимум.
Ну и конечно, надо лучше защищать данные от приложений. Сравните Android, где есть куча разрешений
В snap и flatpak тоже есть разрешения (см. interface для snap и portals для flatpak).
obez
15.10.2019 08:58+1Спасибо за поднятую тему, очень актуальна для меня.
В результате список зависимостей оказывается уникальным для дистрибутива.
Как в итоге зависимости разрешаются? По пакету на дистрибутив?
приходится ориентироваться на самый старый поддерживаемый дистрибутив. Для нас это Red Hat 6.
Я собираюсь на centos 6 + devtoolset-7 и получаю доступ к gcc 7.3.1, без кросс компилятора, вам такой вариант не пойдёт?
Судя по тексту, вся сборка на makefile построена?
CodeImp Автор
15.10.2019 09:08+1Как в итоге зависимости разрешаются? По пакету на дистрибутив?
Проблема с зависимостями, там где она есть, решается созданием нового пакета под дистрибутив, который решил отличиться.
Я собираюсь на centos 6 + devtoolset-7 и получаю доступ к gcc 7.3.1
Не пробовал такое, можно поресёрчить.
Судя по тексту, вся сборка на makefile построена?
Модуль ядра — классический Makefile. User space код собирается с помощью CMake.
Master255
15.10.2019 13:42+1Столкнулся недавно с 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 скрипта компиляции — не больше.gecube
15.10.2019 13:59Какой-то опыт… очень юзерский прям. Мне есть, что сказать по всем пунктам, но прежде чем начать пользоваться новым инструментом — нужно хотя бы минимально его изучить. Я помню, как я вкатывался более 10 лет назад в линукс. Тогда по счастливой случайности я выбрал дистрибутив OpenSUSE. И с тех пор сижу на нем. Были проблемы — и с автоматической установкой, и система ломалась, когда ставишь все пакеты разом. Много чего было. Да и до сих пор не все идеально. Но при наличии желания и прилежности, в принципе, все проблемы решаемы. Ценой времени.
И, да, в винде — как в закрытой системе — часть проблем В ПРИНЦИПЕ нерешаема, но, да, вЕнда изначально более дружелюбна к юзеру.
FRAGIL3
15.10.2019 14:18Вот в цене времени как правило и проблема. Ковыряться с системой хорошо пока это приносит интерес и не мешает основной деятельности, а когда для поддержания работы системы приходится затрачивать ресурсов больше чем на свою работу, тут уже такое…
P.S. Сам бывший линуксоид со стажемkale
15.10.2019 14:34Вот честно, не могу представить, что может заставить «линуксоида со стажем» уйти обратно на Винду, кроме отсутствия профессионально нужно софта или поддержки специфичного оборудования. Сказки про linux «постоянно требующего поддержку» давно уже остались в 2000 годах и попахивают тухлятиной…
FRAGIL3
15.10.2019 15:05Знаете, у меня наверное как раз середина нулевых ассоциируется с большим спокойствием и довольством системой. А дальше сплошное смутное время: отличные для своего времени третьи Кеды изничтожаются четвёртыми, свалил на Гном и Убунту. Убунту начинает с каждым релизом превращаться в жрущего как не в себя тормозного монстра (а из-за различных косяков обновляться приходится чистой установкой), ещё и заменив через пару релизов Гном на Юнити. Переход на третий Гном и кажется дебиан. Гномом можно пользоваться лишь увесив плагинами, но каждые полгода часть из них отваливается. Повсеместное внедрение SystemD, который требует отдельного изучения. Ну и периодические проблемы по мелочи.
Не спорю, можно держать себя в форме, держаться какого-то определённого дистрибутива, привыкнуть к пользовательскому окружению, которое не меняется так драматично как Кеды и Гном, но меня как пользователя в мире GNU/Linux ничего уже особо не держало. Виндовая семёрка уже была вылизана до блеска, я ушёл на неё, а через некоторое время на инсайдерскую десятку.kale
15.10.2019 15:13Значит мне повезло, xfce (на которой я сижу) весьма консервативна, и революции проходят мимо неё… ))
Fenzales
15.10.2019 15:51Поддержу насчёт XFCE, все десятки драм про разные DE за несколько лет прошли мимо меня — конфиги под GTK/Whisker/XFCE Themes кочуют со мной по компьютерам и дистрибутивам, и потребность их трогать возникает крайне редко.
gecube
15.10.2019 16:09Я поэтому на OpenSUSE (повторюсь).
Прошел этапы KDE — Gnome2 — Gnome3 (обплевался) и быстро свалил на Plasma
> Повсеместное внедрение SystemD, который требует отдельного изучения.
По-моему, это лучшее, что случалось с линуксом. Я просто вспоминаю мучения с Sys V Init. Это реально был ад с шелл скриптами. А сейчас… ну, терпимо. Удобно. Да, надо разбираться, но с чем не нужно разбираться? С маком? С виндой? Ну-ну.FRAGIL3
15.10.2019 16:50+1У меня OpenSUSE кстати был первым дистрибутивом, Кеды там как раз были отполированы прекрасно, сидел на нём кажется до релиза 10.3 включительно
kale
15.10.2019 14:15+1Думаю, с ником Вы погорячились, по крайней мере пока…
Все Ваши проблемы с linux, от нежелания элементарно предварительно прочитать доки/форумы о принципиально другой ОС и стремления решить задачу «нахрапом», по шаблонам Виндовс.Кроме этого, обнаружил, что в Убунте нет ярлыков в привычном смысле слова, как в Windows. В 2019 году операционке так и не сделали банальных ярлыков на рабочий стол? После этого можно даже не пытаться говорить о том что эту ОС хоть как-то можно использовать дома.
В Gnome, на котором сейчас строится Ubuntu, ярлыки всегда были до последнего времени но убраны разработчиками, решение действительно странное, но они так «видят». Насколько я знаю, включаются сторонними решениями.Установка Ubuntu №2 — нужен был Python просто для компиляции, а в ОС по умолчанию стоит python3. Откуда мне было знать, что там всё держится на Python? Удалил python3 — интерфейс перестал грузиться совсем. Установки никакие не шли. Восстановить не удалось, миллион разных зависимостей, которые никак не исправить.
Уверен, пакетный менеджер Вас предупреждал что на python куча зависимостей, но Вы решили что умнее. Ну что же, сами себе злобный буратино.
По остальным пунктам, слишком сумбурно и эмоционально-трудно что нибудь диагностировать.
Банально но… учите матчасть…
x67
15.10.2019 14:34Почти классический вопрос — а вы про какой рабочий стол говорите?)
Знаю, что гном, но вопрос актуальности не теряет
Убунта хороша как система, в которой после установки все есть. И там действительно все есть. Кроме злосчастных кодеков. Браузер, офис, плеер и магазин приложений. А большего и не надо.
Если она в таком ключе не подошла, тогда она потребует технических скиллов, как и любой другой линукс дистрибутив. И там уже нужно знать, что трогать, а что нет. Вы ведь системные библиотеки в винде не удаляете, по той же причине не стоит трогать питон. Другое дело, что проку вам от системных библиотек? А в линуксе вы можете на питоне писать и редактировать системные скрипты. И это будет нативнее, чем на винде.
Все ваши проблемы говорят лишь о том, что подход виндовс — попробовать все кнопки подряд тут не работает)
С теми же правами, есть команда судо, которая дает права су на время выполнения программы или время сессии терминала. И это первое, что выдает гугл, как правило)
Вроде все мелочи, а бездумные неосознанные действия в итоге приводят к проблемам.
Arbichev
15.10.2019 14:12Тема очень злободневная. Поскольку я не программист, то не могу сформулировать свою мысль в ваших терминах. Сделаю это на примере из области машиностроения. Задача: нужно соединить две детали. Их можно соединить тремя способами: с помощью заклепок, с помощью сварки и с помощью клея. Технологу никто не навязывает, какой способ соединения деталей выбрать. Предположим, что он выбрал соединение на клею. Существует некий всемирный стандарт соединения деталей на клею. Такой, что потребитель может быть уверен, что на любом заводе эти две детали будут склеены однообразно, и конечный продукт будет соответствовать неким спецификациям.
kale
15.10.2019 14:28Очень хороший пример Вы привели…
90% «мастеров», покупая клей не утруждают себя чтением инструкции на упаковке, яже Мастер, я Знаю… потом их поделие благополучно разваливается и они плюются на клей — «авно», вот Я с предыдущим работал — от то Клей. А производитель не просто так инструкцию пишет, даже у однотипных клеев есть свои нюансы применения, без соблюдения которых они, странно, не работают…
OpenA
15.10.2019 16:23Не сразу догнал. Это типа пост-жалоба на линуксовую инфраструктуру?
Увы она такова и делоgecube
15.10.2019 17:40А потом — как удалять? Желательно, с мусором, которое приложение гарантированно оставит в системе?
А если приложению нужна какая-то системная библиотека? Предлагаете кидаться архивами с полной фс? Мегабайт так на 500?
П.с. минус не я ставил, но позиция у Вас какая-то агрессивная прямOpenA
15.10.2019 19:07папку с программой — в /opt
desktop файл — в домашнюю папку пользователя (если приложение с гуем), или линк в /usr/local/bin если без гуя, или если только себе надо то вообще в профаил.
Блин этож никсы, а не виндоус — что где намусорено будет?
По поводу системных библиотек я не очень понял, если имеются в виду библиотеки из gtk, kde и прочего (как в гнутом софте из репозиториев) то тут просто ничего не поможет уже, такие приложения в снапе тянут с собой каждая половину системы, вплоть там до xcursor и mesa.
Но я все таки понимаю тут свое приложение какое-то (наверное проприетарное), проще и правильней собирать его так что бы оно из папки из своей работало. глибси (и что там еще может быть из таких "системных" библиотек) использовать те что в основных дистрибутивах гарантировано есть.
Как с бинарником поступить я (пользователь линукса) сам решу, если я маинтейнер — заменю либы на симлинки, запакую, добавлю в реп. Если просто-пользователь — просто куда мне надо вытряхну и просто создам кнопку.gecube
16.10.2019 00:25Погодите. А настройки? А файлы данных? Я хочу опцию, что приложение, когда удаляется, то или оставляет их (один кейс — например, для обновления версии), или удаляет (если я хочу почистить хвосты).
то тут просто ничего не поможет уже, такие приложения в снапе тянут с собой каждая половину системы, вплоть там до xcursor и mesa.
Не уверен, что это правильный сценарий, тем более, если приложению нужна интеграция с другими частями системы. Как один из кейсов — у меня стоит Телеграм клиент. В виде отдельного бинарника. Видимо, со своими библиотеками Qt и шрифтами. И что же? Оказывается, что если через него протыкивать ссылку, то запускается гугл хром НЕ В ТОМ окружении. Прикиньте? А я-то думал, что я схожу с ума. Оказывается, что нет.
Как с бинарником поступить я (пользователь линукса) сам решу, если я маинтейнер — заменю либы на симлинки, запакую, добавлю в реп. Если просто-пользователь — просто куда мне надо вытряхну и просто создам кнопку.
ну, окOpenA
16.10.2019 09:54+1Погодите. А настройки? А файлы данных? Я хочу опцию, что приложение, когда удаляется, то или оставляет их (один кейс — например, для обновления версии), или удаляет (если я хочу почистить хвосты).
Не совсем врубаюсь о чем разговор. Все пользовательские настройки приложения лежат в домашней папке и они не удаляются при удалении приложений.
Не уверен, что это правильный сценарий, тем более, если приложению нужна интеграция с другими частями системы. Как один из кейсов — у меня стоит Телеграм клиент.. В виде отдельного бинарника. Видимо, со своими библиотеками Qt и шрифтами. И что же? Оказывается, что если через него протыкивать ссылку, то запускается гугл хром НЕ В ТОМ окружении. Прикиньте?
Так это ты про снап или флатпак какой нибудь — какое они вообще к разговору имеют отношение? Я говорю про классические позикс подходы, самые что нинаесть стандартные.
Если тебя задело отношение к маинтейнерским репозиториям — как к ним еще относиться если это не гитхаб тебе какой нибудь. Это комьюнити которое самостоятельно программы подбирает, собирает, обновляет. Туда нет доступа — ты как разработчик не можешь туда ничего опубликовать ничего обновлять, кроме того их политика может быть такова что твое приложение вообще туда в принципе попасть не может. Маинтейнерские репозитории это не апстор, а компоненты ОС. Макось например тоже из коробки имеет и питон и эмакс и кучу свободных библиотек и приложений, тех версий которые маинтейнеру (в лице эпл) надо, и обновляемые на те версии которые надо, но это не единственный способ получения приложений на макоси и не сказать что бы те другие способы испытывали какие то проблемы с интеграцией. Позтикс он и есть позикс, его не дураки придумывали.
gecube
16.10.2019 09:58Так это ты про снап или флатпак какой нибудь — какое они вообще к разговору имеют отношение? Я говорю про стандартный позикс методы, самые что нинаесть классические.
Нет, не флатпак и не снап. Просто бинарь с офсайта.
Если тебя задело отношение к маинтейнерским репозиториям
Я спокойно реагирую )
Макось например тоже из коробки имеет и питон и эмакс и кучу свободных библиотек и приложений, тех версии которые маинтейнеру (в лице эпл) надо, и обновляемые на те версии которые надо, но это не единственный способ получения приложений на макось и не сказать чтоб эти другие приложения испытывали проблемы с интеграцией в систему.
Все верно. То что мне было нужно — я на мак притаскивал через brew.
gecube
В мире deb-пакетов уровень совместимости поразителен. Один и тот же пакет одинаково хорошо ставится и работает как на Debian 6, так и на Ubuntu 19.04.
Сейчас там был. Ага. Попробуйте CUDA от Ubuntu вкатить на Дебиан соответствующей версии с оф. сайта nvidia. А вот не получится. И проблема даже не в формате deb — он действительно одинаков. А в том, что в разных дистрибутивах разный набор пакетов. В принципе. А один пакет может иметь разные версии, а в манифесте deb, между прочим — хороший тон указывать версии зависимостей. Поэтому лучше уж иметь пакет под каждую версию операционной системы, зато не иметь проблем.
Как пример неграмотной запаковки — могу привести skype. Вроде есть opensuse, вроде есть rpm пакет скайпа. Устанавливаешь — не работает. Начинаешь копать. Оказывается, в rpm забыли добавить несколько зависимостей. Доустанавливаешь руками и все ок.
androidovshchik
Еще забавнее с видеокартами radeon и amdgpu pro драйверами. Для убунты они то есть, но на дебиан (или минт)… Вставили проверку на название ОС, буквально
if (name == "ubuntu"). Та же история и с fedora, выкинь ее, выбирай только между centos и rhel — их слоганamarao
Вы путаете наличие библиотек (зависимостей) и совместимость на уровне стандарта пакетов. У debian есть debian policy, которому криво-косо убунта соответствует (в силу того, что пакеты в основном тырит с testing). А вот в мире бешенного энтерпрайза (aka rpm) — сильнейшая фрагментация.
gecube
Пользователю от этого, к сожалению, не легче. Поэтому самое верное — генерировать по пакеты на версию ОСи. Тогда наверняка проблем не будет (если все остальное сделано нормально).
amarao
Это вызывает свою, отдельную боль. У debian очень стабильный интерфейс наружу (для пользователей) но куда менее стабильный интерфейс для мейнтейнеров (debhelpers), и бегать за некоторыми старыми версиями во имя "у нас нет dh_user" или "нет dh_systemd, так что писать код подкладывания unit'ов руками".
gecube
Жду статьи, как правильно собирать пакеты под дебиан с блекджеком ) Правда, тема очень интересная и не очень освещенная.
amarao
У каждого языка своя специфика. Я знаю как, но я совершенно не знаю, "правильно ли это". Я много пакетировал python, и чаще всего вам достаточно вот такого rules:
А если этого не достаточно, то никакое краткое руковоство вам не объяснит всю боль и сложность мейнтенинга.
gecube
Ну, я мейтейнил свой комплект kernel + nginx. Но ничего интересного за давностью лет не скажу. Вроде бы — там сборка шла наружи, через штатный makefile, а потом уже отдельно происходило опакечивание софта
ilammy
Как правильно — то есть как это делают настоящие мейнтейнеры — читаете от корки до корки большую часть Debian Developers' Manuals (как минимум Debian New Maintainers’ Guide, Debian Policy Manual, Debian Developer's Reference). После этого в боли и мучениях пытаетесь понять, что из этой документации уже устарело и как именно все эти мегабайты правил, советов и рекомендаций можно применить именно к вашему пакету, с учётом его индивидуальных особенностей.
У Debian достаточно высокая планка качества, и планка забюрократизированности процесса в том числе. Несмотря на это, если действительно вдумчиво читать руководство, то можно понять, как собирать пакеты. Там всё-всё написано. Вот я сейчас этим как раз занимаюсь.
Ну, или можно на тяп-ляп вручную запаковать бинарный пакет для своей системы, бегло протестировать его, и заявить о поддержке.
anikavoi
Ничего он не путает. Перечитайте постановку вопроса, там не звучало "… на уровне стандарта..." — там было оголтелое утвердение, которое не соответствует действительности.