И не знайте. То, что я тролль с ЛОРа — дважды неправда. Не тролль, и не с ЛОРа.
В Arch проще реализовать пэкэджинг, только нужно будет сделать соответствующий PKGBUILD.
Сори за откровенность, но немного напоминает классику "кулик+болото". Не важно же, проще/не проще. Вариантов же всего два, делать/не делать. Т.е. добавлять проекту еще один формат пакетов, или забить.
"С ЛОРа" — абсолютно безосновательно. В последний раз был там года три назад.
"тролль" — какая-то ваша личная безосновательная проекция на несогласных с вами людей...
Для упаковки авалонии мы будем из коробки использовать dotnet-packaging, в который я недавно добавил поддержку deb-пакетов. Любители несовместимых с Debian/RHEL дистрибутивов и флетпаков вольны с ними разбираться самостоятельно.
Как интересно все повернулось, собственно:
Начало разговора
Я: Flatpak не подходит для ваших задач.
Вы: Начальник сказал, должно быть во Flatpak.
Я: С целевыми линуксами будьте поскромнее, поддерживайте мейнстрим.
Вы: Линуксы все одинаковые, будем поддерживать скопом.
Сейчас:
Вы: "Любители несовместимых с Debian/RHEL дистрибутивов и флетпаков вольны с ними разбираться самостоятельно."
Вы: qrKot — тролль с ЛОРа, а я весь белый, пушистый и во всем прав...
Т.е. пришли примерно к тому, что я говорил в самом начале. И при этом я — тролль, а вы — на коне и весь в чём-то белом...
Ориентировка на DE+OS вместо OS привлекательнее для пользователей. (Но тут необходимо следовать Guideline, Styleguide, etc.)
О чём я и говорю. "Красиво" — это когда смотрится и ведёт себя так, "как будто здесь и родилось". Сконвертировать на автомате не получится, т.к. сильно разные наборы сущностей. Поддержка "платформоспецифичных" вещей по накладным расходам не сильно дешевле "написания нативного GUI", а потому не особо, имхо, осмыслены.
Другое дело, что для IDE такое поведение (нативное для среды) не надо. "Одинаково везде" для IDE логичней.
У CIL другие принципы сборки, кардинально хотя и не особо отличающиеся от сборки Java.
Различается техпроцесс, этапы, форматы и т.д. Детали реализации, в смысле. На выходе результат примерно один: виртуальная машина, исполняющая универсальный байткод. Собрал один раз, запускаешь внутри аналогичной виртуальной машины на любой из доступных под эту ВМ систем.
Для flatpak'а условной виртуальной машиной (корректнее, наверное, будет формулировка "виртуальное окружение") является его /usr. Своеобразная гарантия, что все, что собрано под лежащие в /usr вещи с аналогичным /usr запустятся. А преследуемые цели — аналогичные JVM и .NET.
В ArchLinux так и сделано, но он не умеет оверхэд, не может SELinux/AppArmor (Соответствующую правку надо сделать для их работы).
Ну, т.е. "пакеты ArchLinux мне кажется правильными, но один хрен не подходят для использования в других дистрибутивах". Т.е. нужно взять пакет арча, распаковать, допилить под него набор правил, перепаковать метаданные (выпилить арчеспецифичные, допилить специфичные для своей платформы), пересобрать цели и упаковать заново в формат пакета, отличный от арчевского… вероятно, в нативный, подходящий для платформы? Где универсальность-то? Зачем эти телодвижения? Если пакет все равно пересобирать, логичнее собирать его из source-tarball'а, или из репозитория исходных кодов. Мне кажется, что арч-пакет в этой цепочке сильно лишняя сущность.
А как по вашему в ArchLinux сделано? Именно так, хотя и добавляются install(в редчайших случаях, для пред/пост установки), .buildinfo(содержащий необходимую для сборки информацию), .pkginfo(содержащий минимальную информацию о пакете), .MTREE(архив, содержащий файловую структуру пакета) и само приложение. Ничего более.
Для Debian'а — мало, для alpine — много. Зачем?
Пакетный менеджер не может быть виртуальной машиной как и виртуальная машина не может быть пакетным менеджером.
Давайте попробуем абстрагироваться от деталей реализации и подумаем о декларируемых целях и функционале. Flatpak — он нужен для того, чтобы собрать/скомпилить приложение, упаковать его в некую сущность, и запустить "как есть" на всех целевых линуксах. JVM, .NET — они для того, чтобы собрать/скомпилить приложение, упаковать его в некоторую сущность, и запустить "как есть" на всех целевых платформах.
Не кажется, что функционал похож? Поэтому и говорю, что Flatpak НЕ пакетный менеджер.
А пакетный менеджер разве не являлся/-тся платформой распространения приложений?
Нет, пакетный менеджер — инструмент управления пакетами. Сравните цели существования пакетных менеджеров и платформы распространения приложений (на примере того же Flatpak'а).
Пакетный менеджер:
проанализировать дерево зависимостей пакетов;
вкорячить содержимое пакета + его зависимости;
определить совместимость пакетов между собой, разрулить конфликты;
установить в систему нативное (собранное под конкретную целевую платформу, вероятно, оптимизированное под нее) приложение/библиотеку/набор сущностей, оптимально подходящее именно этой системе, нужной (при этом конкретно определенной) версии;
определить и автоудалить неиспользуемые версии пакетов, оставить только нужные зависимости;
получить консистентную систему с приложениями (каждое в единственном экземпляре) оптимальных версий.
Цели платформы распространения приложений:
забрать приложение со всеми зависимостями конкретно нужных приложению версий одним куском;
обеспечить гарантированную работу приложения поверх слоя совместимости на всех целевых платформах.
Чуете разницу: нужные нативные, собранные конкретно под целевую платформу библиотеки/приложения и их зависимости vs собранное единожды приложение + слой совместимости.
Итого, Flatpak НЕ есть классический пакетный менеджер, а классический пакетный менеджер НЕ есть платформа распространения приложений.
Да, нормально, спасать не нужно, это просто одна из возможных ситуаций которая может произойти с любым человеком.
В теории произойти она может. Но назвать нормальной ситуацию, в которой, по вашим словам, "от начальника зависит твоя жизнь" сложно.
Кому как, зависишь от руководства, то соответственно такое отношение и будет.
Честно говоря, сильная зависимость от руководства, особенно до уровня "зависит сама жизнь" — серьёзный повод пересмотреть свой подход к жизни и начать в ней что-то менять.
Либо просто пафос...
Понял, посмотрел, ключ filesystem=/[:ro] вроде можно юзать.
Можно, в принципе. Но костыль, при этом "чреватый".
Чуточку оффтопа: вы адекватней, чем показались на первый взгляд.
Вместо этого вопрос для каждого элемента интерфейса: А как для вас лучше выглядит этот элемент?
Пожалуйста, не надо! Подавляющее количество людей (включая и меня) не способны с ноля по опроснику создать что-то вменяемое и юзабельное в плане look-n-feel и юзабилити. Такой треш будет...
Тут так или иначе, одно без другого не может.
Т.е. мы пришли к согласию, что для GUI-фреймворка целевой платформой логичнее считать Desktop Environment, либо, в случае "нативного" исполнения, ориентироваться на уникальные связки DE+OS, чем на OS?
Но раз заговорили про Avalonia (здесь много поскипано, чтобы не захламлять пост)...
Ну, т.е., по сути, собирается оно на тех же принципах, что и любые Java-приложения, только на .Net.
Тут была копипаста ваших высказываний про DBus, пакетные менеджеры и установочные сценарии, но она куда-то сократилась...
Смысл, КМК, в том, что различия уровня есть/нет DBus, SELinux vs AppArmor, SystemD/other Init, доступные версии библиотек, реализация libc и т.д. и т.п. делают "универсальные" форматы пакетов на "уровне" нативных пакетных менеджеров бессмысленными. На выходе мы получим либо жестоко неюзабельное в ощутимом количестве дистрибутивов поделие, либо дикий оверхед по "умелкам" пакета.
Оставь в пакете только само приложение без специфических правил — чем оно лучше тарболла? Убейся предусмотреть все окружения, куда его вкорячить попробуют — все равно все не предусмотришь, только устанешь.
Вот и получается, что "универсальное" решение — это "песочница" + "зависимости включены". Эдакий chroot-на-стероидах со всеми вытекающими. И изоляция, и "свой рут" и "пользуйтесь тем, что внутри". Фактически, если абстрагироваться от деталей реализации, тот же flatpak — вполне себе замена JVM, например. Вот тебе "виртуальное окружение", вот тебе "рантайм", вот тебе "набор доступных API".
При этом можно, конечно, сколько угодно называть flatpak "пакетным менеджером нового поколения", "универсальным пакетным менеджером", но… Брехня все это. Ставить что-то мелкое flatpak'ом — из пушки по воробьям, оверхедом раздавит. Ставить что-то системное — забодаешься изоляцию побеждать. Вот и имеем flatpak — платформа распространения приложений, а не пакетный менеджер.
Послать начальника вы не осмелитесь, если от него будет зависеть ваша жизнь.
Если от этого будет зависеть ваша жизнь, вам придется делать то что он скажет.
Вы меня пугаете! У вас там точно, всё нормально? Может, спасать уже надо?
Странное какое-то отношение к "начальнику". Особенно учитывая, что вы говорили, что проект открытый, свободный, на самомотивации...
Вроде можно использовать опцию share для системных либов другой версии, разве нет?
Вот этот: --share=SUBSYSTEM?
Не, этот нельзя:
Share a subsystem with the host session. This overrides the Context section from the application metadata. SUBSYSTEM must be one of: network, ipc...
(вольный перевод) Расшарить подсистему хостовой сессии. Перекрывает секцию "Контекст" из метаданных приложения. SUBSYSTEM может быть: network (сеть), ipc (inter-process-communication, вероятно имеются в виду сокеты/порты, по аналогии с докеровским EXPOSE).
Насколько я помню с того раза, когда читал доки (возможно, что-то и изменилось, но это будет пахнуть уже сменой концепции), слой может быть SDK и Runtime. В первом — все необходимое, чтобы собрать приложение под второй. По логике, единственный вариант использование flatpak'а в IDE — саму IDE натравливать на SDK, а полученный от сборки выхлоп крутить в Runtime.
Если нужно поконпелять под какие-нибудь микроконтроллеры и прочие отличные от вашей системы — соберите SDK, в нем компилируйте. Потом перекладывайте куда надо. Собрать SDK-слой с "системными либами" достаточно просто — сложить в него либы/заголовки/компиляторы и прочие нужные для сборки вещи с хоста. Это и есть "кошерный вариант". А полученный бинарный выхлоп можно будет положить "как есть" в хостовую систему — и он заведется. Вот это я и предлагал как "сценарий". Если "руко-водитель" считает, что надо иначе — вас мне жаль, а разработчикам flatpak'а в этом вопросе я доверяю больше, чем вашему руководителю.
Большее не удобство для мыши чем для клавиатуры. ИМХО
Что плитки что меню.
Можно попытаться, но будет выглядеть немного коряво.
MS сейчас идет в сторону унификации всего что им доступно.
Начиная от их мобильных устройств(мертвы) до ХабЦентра(Surface Hub если я не ошибаюсь)
Ну, т.е. на выходе имеем некоторый "компромисс" между универсальностью и удобством конечного пользователя. Что-то неудобно для пальца, что-то неудобно для клавиатуры, что-то для мыши. Зато одинаково и "одинаково терпимо" для всех… Просто всем "не совсем удобно", но никаких поводов для обид — все страдают.
И вот так с "конвергенцией" каждый раз… И не только у "Майков".
Я имею в виду что будет правильное преобразование в нативное, для DE.
А вот тут сразу две собаки зарыты:
либо частичный отказ от кроссплатформенности (т.е. с наборами API, доступными отдельно для каждой из платформ), либо абстракция во все поля с универсальными интерфейсами для платформоспецифичных возможностей (фактически, то же самое, но с переносом философских сложностей на сторону разработчиков фреймворка)
если говорить про "правильное преобразование в нативное, для DE" (заметьте, это именно ваша формулировка), то и целевой платформой для GUI-фреймворка должно быть DE, а не "Linux". Т.е. не Windows, MacOS, Linux, а Windows, MacOS, Gnome, KDE, тысячи их, и это еще не вдаваясь в специфику версий.
Есть "универсальное преобразование", и есть "правильное". "Универсальное" — это когда везде одинаково с точностью до закорючки, а "правильное" — это когда по стайлгайдам самого DE. И вот тут — либо крест снимать, либо рясу в трусы не заправлять.
Одна.
Всё-таки, простите за занудство: одна Java или одна платформа? Возможно, сами DE и поддерживают ровно одну IntelliJ-платформу, а платформа-то сколько систем поддерживает?
Если мы говорим про Avalonia-UI, то сравнивать его надо с IntelliJ, а она поддерживает достаточно много целевых платформ, и платформозависимого кода там достаточно много.
Если мы говорим об IDE на базе Avalonia-UI, то, простите, с таким подходом он тоже поддерживает одну целевую платформу — Avalonia-UI. Плюсом, конечно, идет специфика инструментария разработки, специфичного для платформ, но тут, уж извините, ровно с такими же сложностями сталкивается и IntelliJ — тоже тянут слой совместимости для работы с системозависимыми инструментами.
Короче, разницы особо не видно. Может, я чего-то не углядел. Может, вы мне поясните. В чём разница между кроссплатформенной, поддерживающей множество систем вашей IDE и семейством продуктов JetBrains, которые, как оказалось, не кроссплатформенные?
Нет не знаю, но как будет возможность прочту.
Сильно не заморачивайтесь, это просто комик-мем.
"Представляешь, есть 14 конкурирующих стандартов для <вставить нужное>. Необходимо срочно разработать один новый, универсальный, который объединит в себе преимущества и опыт всех имеющися" => "Работа, работа, работа" => "Представляешь, есть 15 конкурирующих стандартов для..."
0install, Snap, Flatpak…
Этого да достаточно, пользователю точно.
Synaptic(APT-DPKG, APT-RPM), Pamac(ALPM(Можно использовать и без pacman. Но по умолчанию он использует его.)), YaST(Zypper-RPM) etc.
Это только графические.
Самое забавное то, что половина всего этого хозяйства родилась именно как попытка создать "универсальный, подходящий всем..." инструмент для управления пакетами.
В конечном итоге, есть apt, есть dnf, есть yum и т.д. и т.п. При этом набор умелок у них, в общем и целом, весьма сходный. Если нужен "инструмент для рядового пользователя, который не разбирается в этих ваших консолях" — без проблем, их есть уже, и при этом они, как правило, часть DE. Пусть и будут. Красивое окошко с рюшечками и кнопочками, которое по нажатию кнопочек тупо шпилить команды в нижележащий ПМ.
Сам-то нижележащий ПМ, простите, заради чего унифицировать? Даже будь формат пакетов одинаковый, установка пакета, собранного под, допустим, Fedora26 в Ubuntu12.04 — достаточно мутная затея. В конце концов, если сильно прижало, есть тот же alien, который вполне сконвертирует пакет. И, по-прежнему, это будет мутная идея.
Потому что линуксы различаются, все же, не только набором пакетов. В конце концов, пакет, собранный для F17 не стоит ставить на F26, а вы предлагаете "единый формат" запилить, и таскать между дистрибутивами?
В конце концов, есть уже "единый и универсальный формат", давно уже есть. *.tar.gz — реально универсальный, и работает везде! Зачем еще один?
Либо внутри, либо DBus тогда уж.
Оба варианта правильные, но случай с balloon-notification попал не в те ворота(Это для Windows).
Вот об этом я выше и говорил. Либо имеем некоторый API, который в линуксе обертывает DBus (к слову, не во всех этих ваших линуксах DBus есть...), а в винде, например, болтает иконкой в трее. Либо имеем две сущности: DBus(который надо дергать в Linux), и TrayIcon(который надо дергать в винде). Оба варианта рабочие, но оба два, простите, выглядят немного костыльно.
Тут нужен четкий ответ.
Слышал, знаю, даже периодически работаю по ТЗ. В случае нереализуемости ТЗ имею привычку сообщать об этом заказчику, прилагая варианты изменения оного до наступления полной реализуемости. Достаточно четко?)
А разве свободный проект не может быть сделан по ТЗ?
Тут, какбы, формулировка зыбкая. ТЗ — это "техническое задание", которое предполагает наличие двух сторон процесса — принимающей ("Заказчика") и выполняющей ("Исполнителя"). И вот тут мотивация первого понятна — он получает продукт. В чём мотивация второго в свободном проекте без оплаты? В случаях самомотивации второй стороны, как мне кажется, оная сторона вполне имеет право отклонить какие-то из требований ТЗ. Или нет?
В случае же общности сторон (т.е. отсутствия ярко выраженных ролей заказчик-исполнитель), как мне кажется:
не стоит использовать формулировку "ТЗ", хотя, это уже не мое дело
можно и нужно, как минимум, обсуждать требования оного ТЗ и соразмерять "хотелки" с "умелками"
Его слушать будут? (Только если тот кто дал задание не упертый балбес.)
А если давший задание — упёртый балбес… Какбэ, кхм… А почему вы его лесом не послали, например? Или не сказали: "Надо? Прям никак без этого? Сделай!" Чем он вас мотивирует? Он держит ваших родственников в заложниках? Бьёт? Угрожает? Шантажирует?
Упёртый балбес, руководящий проектом, как правило, имеет печальное влияние на судьбу проекта в целом. Если разработчиков сильно более одного, и весомая часть считает руководителя неправым упёртым балбесом… Ну, форкнуться можно же?
Flatpak сам ведь использует /usr => и его приложения могут использовать /usr.
Видимо от этой логики все и идет.
Ну раскройте уже глаза "постановщику задачи". Ссылку на официальную документацию дайте, что ли, почитать.
Вот прямо оттуда:
Each runtime can be thought of as a /usr filesystem. Indeed, when an application is run, its runtime is mounted at /usr.
Рантайм флатпака — это, условно, его /usr. В момент запуска приложения, содержимое его рантайма монтируется как /usr. Вот ровно то, что в рантайме пакета лежит, в /usr для флатпака и будет. Надо системные библиотеки? Скопируйте. Надо другие версии — положите куда требует спецификация. Не хотите класть — ищите другие инструменты.
>> Системный трей относится только к оболочкам, но не к ядру или системе!
>> А пояснение верно. Хотя замечу что Linux это не ОС, а всего лишь ядро.
>> Если претензии летят в сторону Linux, а не к прим. ArchLinux, то все претензии идут к ядру, а не к ОС(Учти этот факт).
Вот я и намекнул предыдущему оратору, что он с претензией по трею не по адресу. И, в качестве сарказма, написал, мол, трей — виновато ядро, фон рабочего стола — виновато ядро. Вы восприняли это за мое личное мнение. Это сарказм был.
>> Хмм… По поводу плиток и плиточного UI, для управления K+M они настолько же удобны как и кнопки которые не удобно тыкать пальцем если они маленькие.
>> Заголовки окон на полэкрана для XHIDPI только, а вот кнопки для XHIDPI согласен маленькие.
Все же, согласитесь, плитки таки менее удобны для клава-мышь. Не критично, но менее удобны, чем классическое меню.
Подсказка №1: объем телодвижений между соседними пунктами меню, и между плитками в разных углах экрана.
Подсказка №2: меню реализует древовидную иерархию, причем с возможностью видеть предыдущую ступень иерархии целиком. На плитках — нереализуемо. Не могу сказать, что эта самая иерархия — то, без чего совершенно невозможно обойтись, но таки штука временами удобная.
>> Не все. Что сделано по стандарту без шагов в сторону, то везде будет работать одинаково.
Имеется в виду, что везде будет работать одинаково не-нативно?
>> Если все сделано как надо, а именно чисто специфичные для UI toolkit'а функции не используются, то LnF будет везде один и тот же.
Ну, т.е. да, не нативно. Чем тогда Qt/QML не угодил? Хотя ладно, не будем вдаваться в холивары.
Короче, определиться нужно: одинаково-на-всех-платформах vs нэйтив-лук-энд-фил. Либо-либо. Вот тут нельзя сесть на 2 стула сразу.
>> Галочка, крест и круг(Есть, нет, через костыль)
Ну, т.е. вы согласны, что всю табличку заполнить галочками невозможно? Это и называется формально недостижимо.
О ДжетБрейнс
>> Они пишут свой.
О чём я и упоминал: свой с необходимым минимумом. Если хотите, MVP.
>> У них одна платформа.
В смыыыысле? Win/Lin/MacOS — одна? Или Java одна? Т.е. гуи-фреймворк поверх Xamarin/.Net, запущенный на Win/Lin/MacOS — это РАЗНЫЕ платформы, а гуи-фреймворк поверх Java, запущенный на Win/Lin/MacOS — ОДНА. Здорово живем!
>> Они пишут свою платформу, им не нужны гайдлайны.
Вот я и пытаюсь выяснить, все же: в AvaloniaUI — тот же подход «нам не нужны гайдлайны, у нас своя платформа», или таки «везде нативненько». Просто предыдущий оратор декларировал одно, а описывал совершенно другое.
>> Смысл сея цитаты был таков, что сделаем минимум для работы системы + добавим универсальный ПМ для использования его пользователем который будет ставить ему софт который ему нужен.
Знаете же историю про «14 конкурирующих стандартов»? Универсальный ПМ не взлетит. Их и так достаточно.
Так что оставьте уже базовый ПМ в покое. Логичнее сделать надстройку над базовым ПМ с рюшечками и кнопочками. Ну так есть уже. И тоже не одна штука.
>> Да в мнении есть ошибка, но мною она не может быть воспринята в принципе.
А зря.
>> Разные реализации ABI, но все равно являются пакетами как ни крути.
Ну, т.е. в тот же Debian вы можете просто пакетом положить libmusl и ничего не изменится? Какбэ, есть мнение, что у вас полсистемы отвалится. Пакет — это такая штука, которая, концептуально, не влияет на работоспособность системы в целом, и при замене на аналог не требует пересборки всей остальной системы. Ну, т.е. libc, конечно, ставится пакетом, но, как правило, это формальность. Это часть базовой системы. Хотите заменяемости libc — положите рядом еще один репозиторий целиком, собранный на новой версии libc. Странное поведение для рядового пакета, не?
>> LSB — предоставляет всего лишь стандартную базу и всё не более, а также стандарт и его реализация не есть обязательное требование.
Ну да, это всего лишь спецификация с рекомендациями на тему «чего в этих ваших линуксах должно быть». И если уж строить IDE, работающее поверх набора системных инструментов, стоит завязываться именно на подобную спецификацию, а не на мифический «Линукс». Линукс слишком неоднороден.
>> POSIX — стандарт и его реализация не есть обязательное требование.
С POSIX'ом — аналогично.
Дело в том, что если вы пишете IDE под набор каких-то системных библиотек и с учетом наличия какого-то «стандартного инструментария», вы изначально предполагаете, что он есть. А это не факт. Самое логичное — завязаться на спеку вроде LSB, или написать свою, мол, для работы нам нужно (дальше список...). Не пытайтесь реализовать сборку под ВСЕ линуксы, иначе неизбежны моменты удивления типа «как так ping'а нету???».
В конечном итоге, достижимо создание продукта под некоторое подмножество Linux-based осей, и сильно лучше будет, если это подмножество будет формализовано, желательно с указанием спецификации, что, в каком виде, каких версий и почему нужно для всего комбайна в целом.
>> Не логично, DE != GUI-Framework.
В том и проблема, что логично… DE — desktop environment, т.е. ОКРУЖЕНИЕ рабочего стола. Со своим набором look-n-feel, пользовательских паттернов, гайдлайнов и прочим. Если эти части проигнорировать, то «родным» приложение не будет выглядеть ни на одной из платформ. Т.е. будем одинаково средненько везде. Вот, допустим, изначально заточенное под винду приложение имеет менюху вверху, кнопки действий внизу под активным содержимым. Берете «как есть», переносите в окружение третьегнома… На выходе в третьегноме есть набор изначально системных приложений с право-верхним расположением кнопок и без глобального меню, и ваше — белая ворона. И так на каждую пару окружение-окружение. С линуксом сложность еще и в том, что линукс, условно, один, и все системы на его базе воспринимаются как единое целое, а между тем набор поведений, принятый в гноме, будет так же дико смотреться на KDE, как и принесенный из MacOS.
>> Претензии к GTK+, GDK и Qt слышать более логично если речь идет об GUI-Framework.
Вот тут вы что-то перепутали. В споре о гуи-фреймворках, согласен, слышать претензии к GTK+ и Qt. GDK-то при чем? Это же просто низкоуровневая библиотека примитивов, используемая как бэкенд GTK? Это же не GUI-фреймворк?
>> Пример, нарисовать balloon-notification с сообщением что компиляция завершена.
Например, для данного случая, есть 2 пути:
1. Поступить как ДжетБрейнс — реализовать нотификашки внутри окна приложения, безотносительно трея.
2. Поступить «правильным путем». Допустим, в том же Gnome используется libnotify. Отлично оповещает, к слову.
>> А про техническое задание ничего не слышали?
Допустим слышал. Так это свободный проект энтузиастов, или вы на зарплате?
>> Если в ТЗ указано что надо сделать и ещё указано что разработать это для Flatpak, а также сказано использовать системные библиотеки другой версии и при этом их нельзя бросать в Flatpak-пакет, то хочешь не хочешь но по заданию должен будешь сделать как там указано.
Надо, например, указать разработчику ТЗ на «противоречащие параграфы» этого самого ТЗ.
1. Собрать во flatpak
2. Системные библиотеки
3. «другой версии» — это отличные от тех, которые есть в системе?
4. нельзя все это хозяйство положить внутрь flatpak
Вот прям реально невыполнимо. Ну нельзя flatpak'у давать доступ к системному /usr, он именно с этой целью и делался, чтобы у него туда доступа не было!
Ну и вообще, как-то странно звучит «использовать системные библиотеки другой версии». Это, в смысле, такие же, как в базовой системе, но другой версии? А почему же не положить их в SDK-пакет? Просто «хотелка» постановщика задач? А почему ему никто не сказал, что так не делается?
Блин, тег «сарказм» таки нужен. Вот вы уже меня обвиняете «Ну конечно при всех раскладах виновато ядро ОС, куда же ещё смотреть кроме как не на самого себя.»
Проследите, пожалуйста, историю дискуссии, если не лень. Дело в том, что я как раз был противником позиции «виноват линукс».
Предыдущий оратор из ПРОТИВОПОЛОЖНОГО лагеря выдвинул сентенцию «Из вашего Линукса вон системный трей выпилили!» Ну неправда же! Не выпиливали! Поясню: в Линуксе как таковом системного трея никогда и НЕ БЫЛО. В ТретьеГноме был, факт. Уродливый и неюзабельный. Да, выпилили. А в KDE, например, оставили. НО… Оба этих факта к Линуксу как таковому отношение имеют весьма и весьма опосредованное. Пляски с треем — это ГномоПроблемы. Не мешайте их с ЛинуксоПроблемами — их и без ГномоПроблем хватает.
Теперь о моей поизции по UI-тулкиту. Видимо, надо обосновать:
а) слабореализуемо
т.к. каждая платформа имеет свой набор поведений, инструментов, best-practices и т.д. и т.п. Что-то универсальное… Хм, как бы, пробовали уже. Canonical пробовал, Microsoft пробовал. «Конвергенция» не взлетает. На выходе мы имеем «плитки», в которые удобно тыкать пальцем, но чудовищные с точки зрения управления мышью и, уж тем более, клавиатуры. Мы имеем заголовки окон в полэкрана на десктопе, и имеем кнопки 15х15px на смартфонах, в которые вы хрен пальцем попадете. Все универсальное заведомо хуже нативного.
б) расходится с политикой поставщиков ОС
Гайдлайны у каждого свои. И даже можно оформить темы, чтобы оно «нативно выглядело» на каждой платформе. При этом есть еще UX и набор паттернов поведения, которые автоматически не сконвертируешь. Ну вот никак, реально. Все равно придется платформо-зависимую часть пилить, хоть убейся. Или забить просто на native-look-and-feel… Но тогда о какой «полноценной поддержке» можно говорить?
в) формально недостижимо
Вот составьте табличку умелок и проставьте галочки, на каких платформах что реализовано. Вот прямо на пункте «значки в трее» ваша затея и поутихнет. Где-то они есть, где-то не предусмотрены, а где-то плагинами (вы тут плюс или минус ставить будете?) Короче, никогда у вас вся табличка плюсами не будет заполнена, т.е. ФОРМАЛЬНО НЕДОСТИЖИМО.
Если говорить про JetBrains, то эти ребята не пытаются взять «универсальный кросплатформенный гуи-фреймворк» и на нем реализовать. Они запилили «необходимый минимум» под нужные им платформы, и ничего, норм, живут. При этом запускаются они далеко не под каждым линуксом, например. И не пытаются запилить версию своих DE под мобильные платформы, зная, что они там на фиг не сдались. Да и по поддержке гайдлайнов они не заморачиваются. Одинаково кладут болт на гайды всех платформ, на которых работают.
>> Знаешь подвижки в плане «создадим единую пакетную систему для всех Linux-kernel based систем» рано или поздно должны быть.
Вот это тоже не выстрелит. Были уже попытки. Вполне обоснованно не взлетели. Кто-то придерживается политики «ставим только то, что необходимо», и его пакетный менеджер ведет разветвленное дерево зависимостей, а в пакетах тонны метаинформации на тему что-от-чего-зависит-и-в-каком-порядке-ставить. Кто-то придерживается более утилитарно-интерпрайзного подхода вида «винты дешевые, чо мы паримся», и вот он с икренним недоумением смотрит в количество метаинформации в пакетах первых. А третий вообще все это пытается в 2-гигабайтную SD-карточку упихать, для него кретинами выглядят и те, и другие. Есть, вероятно, «золотая середина», которая будет одинаково неудобна всем. Но зачем?
>> А дисты Linux если и имеют различия то только в пакетной составляющей.
А вот это уже совсем ошибочное мнение, извините за прямоту. Начать с того, что есть, например glibc. А есть еще libmusl, а есть eglibc. А еще есть AppArmor vs SELinux. А кроме пакетных менеджеров есть еще и инит… А еще не то LSB, даже POSIX не все дистрибутивы поддерживают…
Так что, дорогой мой созидатель, пожалуйста, не смешивайте проблемы Linux'а и проблемы DE. Винду, например, можно за гуй ругать — они, по сути, неотделимы друг от друга. В Линухе, исторически так сложилось, мухи отдельно, котлеты отдельно.
Поэтому со стороны разработки ГУИ-фреймворка логично слышать претензии к Гному, к КДЕ, к ТысячиИх. Ругать Линуху за заскоки гнома — странное занятие.
С точки же зрения IDE, т.е. разработческой платформы — тут да, вопросы, вероятно, больше к Linux'у, но среди этих вопросов уж точно нет «ой, трей отпилили». Не представляю, если честно, зачем реально IDE иконка в систрее.
Ну а про «нужны именно системные библиотеки» — нафига тогда во flatpak пихать, если системные нужны? А если уж прижало именно во flatpak — ну, скопируйте системные вовнутрь, в чем, собственно, проблема?
Какбэ ваша отсылка к «андроид-телефоны рутуются»… на фоне разработки хоть сколько-нибудь серьезного инструментария выглядит, как минимум, странно. Рутование, согласно политике производителя — это таки не функция системы, а вполне себе взлом, ведущий к отказу от гарантии. Поэтому позиционировать факт рутования андроида как его фичу… Ну, какбэ, взломайте песочницу flatpack'а — в линухе рут доступен изначально, имеет все права и везде, а потому обход песочницы в линухе должен быть проще. Не забудьте повесить табличку при установке, мол, мы используем патченный flatpack, и для использования нашего софта надо отключить AppArmor и SELinux, если таковые имеются. Будет вполне в стиле советов под винду из цикла «Отключите антивирус и брендмауэр».
Только, ради всего святого, не выдавайте такое поведение за норму. «Для запуска нашего софта под андроид, необходимо рутануть устройство» — это НЕ нормально.
А по сути ваших задач, мнение мое следующее:
1. Кросплатформенный UI-тулкит — это, конечно, хорошо, но:
а) слабореализуемо
б) расходится с политикой поставщиков ОС
в) формально недостижимо
2. IDE на базе кросплатформенного UI-тулкита… Какбэ, в некоторых случаях кроссплатформенность IDE идет только во вред.
3. Выбор для реализации этого проекта неполноценно кроссплатформенного .NET — тем более странно. У вас внутри наполовину Mono, наполовину .NetCore. При этом все это в стадии жесточайшей беты и ваще жесть.
4. Для разработки под встраиваемые железки песочная изоляция — самое оно. Внутри песочницы вы будете иметь ровно те заголовочные файлы, версии библиотек и прочую кашу, которые будут доступны вам на целевой системе. Гарантия того, что где-то не просочится десктопный инклюд с вашей девелоперской машины — это только к лучшему. Еще раз повторю, для сборки под целевую платформу лучше иметь весь рантайм + исходники/либы платформы внутри песочницы, чтобы потом не удивляться, почему «а на моей машине работает».
5. Претензия по поводу пакетов для Linux — она из рода «я под винду собрал, а на макоси не запускается! Оказывается, пересобирать надо! Как так?» Дистрибутивы линухи различаются между собой примерно как Windows и Android. Поэтому претензия к «жопа собрать один пакет под линукс» — она странная. Вы же не сетуете, что у вас один бинарник под виндой и под макосью не запускается. Просто перестаньте поддерживать «Linux». Нету никакого «Linux'а», есть Ubuntu отдельно, Fedora/RH отдельно, Suse, Arch — тысячи их. Поддерживайте целевую платформу, а не зоопарк целевых платформ. Или отказывайтесь от поддержки целиком, если процент пользователей там не критичен. Даже доведи разрабы flatpack до совершенства, до полной усраться-совместимости c миллионом дистрибутивов Linux, вот реально оно на том же Alpine не заведется, и на тысяче других. Потому что они принципиально про другое.
6. Ну а последний абзац — он вообще про Xamarin-проблемы. Т.е. Xamarin-овцы упаковали во флетпак — виновата, естественно, Linux-экосистема. У вас были проблемы с разработкой на Mono под Linux — проблема Linux-экосистемы… Короче, при всех раскладах виноват именно Linux, причем в целом.
Давайте конкретизировать претензии и ограничивать аппетиты.
Странно обвинять линуксовое средство доставки приложений в том, что оно не такое, как под мак или под windows. Оно, скорее, такое, как под Android, например. Но в Гугл вы же пальцем не тычете?
Ну вот каким боком тот же Android SDK является дистроспецифичным?
А кто-то говорил про Android SDK?
системный GNU Make или прочитать содержимое системного /usr/include
Вот ЭТО вы просили, и да, ОНО дистроспецифичное.
С точки зрения IDE достаточно знать путь к ним и всё.
А с точки зрения компилятора — недостаточно. Надо еще, чтобы версии библиотек внутри песочницы совпали с версиями снаружи, например. И это превращает весь механизм в пшик, никому не нужный и не работающий.
Вместо этого предлагается делать поддержку для каждого дистра по-отдельности
Ну вот неправда же ваша. Предлагается делать поддержку под SDK той версии, которая во flatpak'е или snap'е. Понимаете? Именно под ту версию, которая в базовом лейере пакета. Т.е. прямо так и говорят: не заморачивайтесь со спецификой различных дистрибутивов, пишите под ваш образ! А уж он будет работать на всех дистрибутивах — это уже наш головняк.
вместо решения для портабельной установки программ аки в макоси предлагают принудительно запихивать всё в песочницу
Ну вот это и логично же. Макось — это коммерческая ось, направление развития которой курирует вполне себе конкретная фирма, и конкретные люди. И, если эти люди договорились между собой, что библиотека Икс во всех продуктах будет версии Игрек с версией билда Зет, она там будет. А в линуксе не договорятся.
Поэтому от системных библиотек вас изолируют, и правильно делают.
Вот смотрите, вы сетуете на то, что дистрибутивы сильно разные, и под каждый из них приходится пилить свои костыли. При этом говорите, что песочница, абстрагирующая от деталей реализации дистрибутива, зло.
Зачем вообще этот уровень абстракции, если вам нужен доступ к дистроспецифичным вещам? Нужны дистроспецифичные вещи — пишите под конкретный дистрибутив.
В пример вы приводите Винду, в которой ситуация, вроде как, устаканилась. Ок, только вcя разница в том, что винда одна, а линуксов — море.
Хотите windows-way? В чем проблема, определитесь с конкретным дистрибутивом, который будете поддерживать. Получится стабильно и со своей спецификой.
Хотите, чтобы работало на всем зоопарке линуксов? Суйте приложение в песочницу-абстракцию и не выпендривайтесь.
В сценарии, заради которого все затевалось, системный /usr/include читать и не надо. Читать надо тот, который для этой песочницы специальный.
Понимаете, философия в том, что относительно стабилен линукс ровно по линии glibc. В ядре — нестабильное ABI, заради развития. В юзерспейсе — вообще форменный угар и содомия. Единственное решение — в песочницу положить все от glibc и выше в сторону юзерспейса. Т.е. и gtk у вас там свой будет, фиксированной версии, и всяческие lib*.*.*.so. Вот именно так гарантируется, что тот же фотошоп не отвалится при обновлении из-за того, что в гноме вылилят DBus, а Gentoo перейдет на BusyBox (так, навскидку, в порядке бреда).
если я делаю IDE
Если вы делаете IDE для разработки приложения-под-песочницу — все норм. У этого IDE прям ровно нужные /usr/include и версии конпеляторов будут. Если общесистемное IDE — вы опять не по адресу. Оно заради пользовательского софта пишется.
Почему хотелось бы бека на «быстрых» языках со статической типизацией и без джаваскриптов, так потому что тогда все будет работать быстрее и требовать меньших нагрузок (у меня дома точно не гугловский сервер стоит).
Вот именно, что дома не сервер. Поэтому основной вопрос к фронту таки. Поверьте, в браузерном исполнении он будет тормозить сильнее, чем бэк.
Концепция, очевидно. Flatpak — песочница для сторонних (3rd party) пользовательских приложений. Нравится это или нет — с этим придется смириться. Для различных фоторедакторов, книг рецептов и прочих веселых ферм — самое оно. Вот реально не надо им доступ за пределы «хомяка».
Если вы системный софт в него пытаетесь запаковать… Ну, видимо, вы используете flatpak не по назначению. Он не плохой, он просто для этого не предназначен.
Snap, к слову, тоже не совсем ваш use-case. Devmode — это режим отладки приложения, не предназначенный для боевого применения, однако. Собственно, запретить вам пользовать devmode в своем проде никто не запретит, но широкого применения данная модель не предполагает.
Другое дело — плагины. Всё, к чему вам изнутри песочницы доступ нужно иметь, вы можете положить в плагин, а потом присобачить к вашему приложению (в случае со snap). Это, типа, «кошерный» путь применения.
На OSX/Windows обычно в таких случаях спрашивают путь к утилите и/или предлагают её доустановить.
Собственно, так сделать, особо, никто не мешает. И даже будет работать примерно в 50% случаев. Нужно, буквально, D-Bus и установщик, который на нем висит. Т.е. реализуемо, например, в Ubuntu или Fedora. Однако «правильный путь» — всобачить то, от чего зависит ваш пак, в зависимости этого самого пака и поставить отдельным слоем.
Собственно, подача про osX и win — ну… какбэ там тоже лютейший и корявейший костыль, например…
В данном случае, маловажно, на чем написан бэкенд. Собственно, в данный момент фронт гуглоофиса с бэкендом «общается» по rest-api (собственно, сам апи можно и пощупать напрямую, он доступен). Бэк же, вот реально без вариантов, валит все это в какую-то базу данных.
На выходе 3 проблемы:
1. Упаковать «как есть» веб-приложение и выдать его за десктопное… Тормозить будет люто. Да и смысл? Чем будет отличаться от гуглосервиса?
2. Даже переписать фронт, избавиться от промежуточного REST'а… И для офиса вертеть на своей машинке базу данных? Оно реально надо?
3. Переписать фронт, переписать бек… Т.е. «переписать все»? А зачем тогда исходники гугла?
Если не возражаете, постараюсь изложить свое видение проблемы (поправьте, если я где-то не прав в фактической составляющей).
В данный момент ситуация, скорее, патовая, и навешивание ярлыков «прав», «не прав», «фанатик» и «религиозные убеждения» ничего не изменит и мир, тем более, не спасет.
Есть конкретная группа людей, которая «пилит» ядро Linux. Они, что логично, определяют то, как ядро должно работать, и какие его части для чего предназначены.
Есть Nvidia, которая, по вполне очевидным причинам, в модель, данную разработчиками ядра, «ложиться» не хочет. Для того, чтобы заработало «как задумано», нужно предоставить спецификации.
Учитывая открытую модель разработки ядра, спецификации придется предоставить в открытый доступ, т.е. всем желающим. Открытые же спецификации позволят «разлочить» некоторый функционал на более бюджетных моделят видеокарт Nvidia, что неизбежно уронит покупки более дорогих девайсов.
Т.е., с одной стороны, есть совершенно четкие и определенные спецификации, которые гарантируют корректную работу драйвера при соответствии API, и нежелание разработчиков ядра положить болт на свои спеки мало того, что понятно, так еще и похвально. При этом есть нежелание Nvidia урезать свои доходы, которое не менее понятно, но, в данном контексте, значительно менее похвально.
Почему такой попы нет на Windows/osX? Также совершенно очевидно. Обе системы закрыты, т.е. спецификации не «утекут». На предоставлении спецификаций производителям проприетарных систем Nvidia не теряет в доходах.
Первые достойны уважения хотя бы за то, что делают ядро. Вторые достойны права не любить первых ввиду доставленных неудобств.
В данном контексте первые — весьма достойные люди безо всяких «хотя бы за». Право вторых же «не любить первых» весьма сомнительно. В конце концов, проблема создана не на ровном месте, а по вполне объективным причинам. Так что вторым можно порекомендовать, скорее, отказаться от продукции Nvidia в пользу Intel/AMD. Нет, не потому, что Nvidia плохая или что-то подобное, а потому, что, по объективным причинам, реализовать корректную работу вышеозначенной продукции в рамках Linux не представляется возможным. Если же корректная работа Nvidia-девайса более приоритетна, чем операционная система, может быть, вторым просто поменять ОС?
Собственно, эмулятор терминала в логику flatpak таки не укладывается. Все же, именно эмулятор терминала не совсем рядовое пользовательское приложение.
И сделано это специально. Почему так — для меня загадка.
Вот тут то, как раз, загадки нет. Flatpak делался, по сути, как реализация модели распространения приложений по типу Android'ной. Т.е. вся философия в том, чтобы не тащить уйму непонятно кем написанного гамна разной степени корявости в репозиторий системы. А вот этому гумну, как раз, изоляция не помешает.
Собственно, это зачатки аналога Play/Appstore под линуху. Логическая цепочка, как раз, очевидна: Унификация платформы -> Способ монетизации -> Появление тучи софта разной степени корявости -> Увеличение пользовательской базы -> Подтягивание A-class софта -> «Причесывание» магазина приложений.
Собственно, именно то, что Google сделал с Android. В принципе, вполне может выстрелить.
И да, как «коробка» для эмуляторов терминалов и системного софта оно не задумывалось от слова «совсем». А пользовательские «ништяки», типа клиентов всяких «одноклассников», «вайцапов» и «веселых ферм» туда вполне себе ложатся.
Для «условно-систеного» же софта… Ну, тут, собственно, какфсигда, 2 пути. Либо щупайте snap (благо, поддержку теперь и Redhat условно анонсировал) — у него умелок побольше, либо пилите пакет для системы. Собственно, вызов консольной тулзы по имени в сценарий «песочницы для гарантированной совместимости» и не укладывается. В нижележащей системе консольной тулзы, которую вы вызываете, может и не оказаться. Это уже дистроспецифичная вещь — т.е., в некоторых случах может не сработать. Короче, вполне предсказуемая и даже логичная модель «жрите, что дают, если надо еще — заказывайте у шеф-повара».
И не знайте. То, что я тролль с ЛОРа — дважды неправда. Не тролль, и не с ЛОРа.
Сори за откровенность, но немного напоминает классику "кулик+болото". Не важно же, проще/не проще. Вариантов же всего два, делать/не делать. Т.е. добавлять проекту еще один формат пакетов, или забить.
"С ЛОРа" — абсолютно безосновательно. В последний раз был там года три назад.
"тролль" — какая-то ваша личная безосновательная проекция на несогласных с вами людей...
Как интересно все повернулось, собственно:
Начало разговора
Сейчас:
Т.е. пришли примерно к тому, что я говорил в самом начале. И при этом я — тролль, а вы — на коне и весь в
чём-тобелом...О чём я и говорю. "Красиво" — это когда смотрится и ведёт себя так, "как будто здесь и родилось". Сконвертировать на автомате не получится, т.к. сильно разные наборы сущностей. Поддержка "платформоспецифичных" вещей по накладным расходам не сильно дешевле "написания нативного GUI", а потому не особо, имхо, осмыслены.
Другое дело, что для IDE такое поведение (нативное для среды) не надо. "Одинаково везде" для IDE логичней.
Различается техпроцесс, этапы, форматы и т.д. Детали реализации, в смысле. На выходе результат примерно один: виртуальная машина, исполняющая универсальный байткод. Собрал один раз, запускаешь внутри аналогичной виртуальной машины на любой из доступных под эту ВМ систем.
Для flatpak'а условной виртуальной машиной (корректнее, наверное, будет формулировка "виртуальное окружение") является его /usr. Своеобразная гарантия, что все, что собрано под лежащие в /usr вещи с аналогичным /usr запустятся. А преследуемые цели — аналогичные JVM и .NET.
Ну, т.е. "пакеты ArchLinux мне кажется правильными, но один хрен не подходят для использования в других дистрибутивах". Т.е. нужно взять пакет арча, распаковать, допилить под него набор правил, перепаковать метаданные (выпилить арчеспецифичные, допилить специфичные для своей платформы), пересобрать цели и упаковать заново в формат пакета, отличный от арчевского… вероятно, в нативный, подходящий для платформы? Где универсальность-то? Зачем эти телодвижения? Если пакет все равно пересобирать, логичнее собирать его из source-tarball'а, или из репозитория исходных кодов. Мне кажется, что арч-пакет в этой цепочке сильно лишняя сущность.
Для Debian'а — мало, для alpine — много. Зачем?
Давайте попробуем абстрагироваться от деталей реализации и подумаем о декларируемых целях и функционале. Flatpak — он нужен для того, чтобы собрать/скомпилить приложение, упаковать его в некую сущность, и запустить "как есть" на всех целевых линуксах. JVM, .NET — они для того, чтобы собрать/скомпилить приложение, упаковать его в некоторую сущность, и запустить "как есть" на всех целевых платформах.
Не кажется, что функционал похож? Поэтому и говорю, что Flatpak НЕ пакетный менеджер.
Нет, пакетный менеджер — инструмент управления пакетами. Сравните цели существования пакетных менеджеров и платформы распространения приложений (на примере того же Flatpak'а).
Пакетный менеджер:
Цели платформы распространения приложений:
Чуете разницу: нужные нативные, собранные конкретно под целевую платформу библиотеки/приложения и их зависимости vs собранное единожды приложение + слой совместимости.
Итого, Flatpak НЕ есть классический пакетный менеджер, а классический пакетный менеджер НЕ есть платформа распространения приложений.
В теории произойти она может. Но назвать нормальной ситуацию, в которой, по вашим словам, "от начальника зависит твоя жизнь" сложно.
Честно говоря, сильная зависимость от руководства, особенно до уровня "зависит сама жизнь" — серьёзный повод пересмотреть свой подход к жизни и начать в ней что-то менять.
Либо просто пафос...
Можно, в принципе. Но костыль, при этом "чреватый".
Пожалуйста, не надо! Подавляющее количество людей (включая и меня) не способны с ноля по опроснику создать что-то вменяемое и юзабельное в плане look-n-feel и юзабилити. Такой треш будет...
Т.е. мы пришли к согласию, что для GUI-фреймворка целевой платформой логичнее считать Desktop Environment, либо, в случае "нативного" исполнения, ориентироваться на уникальные связки DE+OS, чем на OS?
Ну, т.е., по сути, собирается оно на тех же принципах, что и любые Java-приложения, только на .Net.
Смысл, КМК, в том, что различия уровня есть/нет DBus, SELinux vs AppArmor, SystemD/other Init, доступные версии библиотек, реализация libc и т.д. и т.п. делают "универсальные" форматы пакетов на "уровне" нативных пакетных менеджеров бессмысленными. На выходе мы получим либо жестоко неюзабельное в ощутимом количестве дистрибутивов поделие, либо дикий оверхед по "умелкам" пакета.
Оставь в пакете только само приложение без специфических правил — чем оно лучше тарболла? Убейся предусмотреть все окружения, куда его вкорячить попробуют — все равно все не предусмотришь, только устанешь.
Вот и получается, что "универсальное" решение — это "песочница" + "зависимости включены". Эдакий chroot-на-стероидах со всеми вытекающими. И изоляция, и "свой рут" и "пользуйтесь тем, что внутри". Фактически, если абстрагироваться от деталей реализации, тот же flatpak — вполне себе замена JVM, например. Вот тебе "виртуальное окружение", вот тебе "рантайм", вот тебе "набор доступных API".
При этом можно, конечно, сколько угодно называть flatpak "пакетным менеджером нового поколения", "универсальным пакетным менеджером", но… Брехня все это. Ставить что-то мелкое flatpak'ом — из пушки по воробьям, оверхедом раздавит. Ставить что-то системное — забодаешься изоляцию побеждать. Вот и имеем flatpak — платформа распространения приложений, а не пакетный менеджер.
Вы меня пугаете! У вас там точно, всё нормально? Может, спасать уже надо?
Странное какое-то отношение к "начальнику". Особенно учитывая, что вы говорили, что проект открытый, свободный, на самомотивации...
Вот этот: --share=SUBSYSTEM?
Не, этот нельзя:
Насколько я помню с того раза, когда читал доки (возможно, что-то и изменилось, но это будет пахнуть уже сменой концепции), слой может быть SDK и Runtime. В первом — все необходимое, чтобы собрать приложение под второй. По логике, единственный вариант использование flatpak'а в IDE — саму IDE натравливать на SDK, а полученный от сборки выхлоп крутить в Runtime.
Если нужно поконпелять под какие-нибудь микроконтроллеры и прочие отличные от вашей системы — соберите SDK, в нем компилируйте. Потом перекладывайте куда надо. Собрать SDK-слой с "системными либами" достаточно просто — сложить в него либы/заголовки/компиляторы и прочие нужные для сборки вещи с хоста. Это и есть "кошерный вариант". А полученный бинарный выхлоп можно будет положить "как есть" в хостовую систему — и он заведется. Вот это я и предлагал как "сценарий". Если "руко-водитель" считает, что надо иначе — вас мне жаль, а разработчикам flatpak'а в этом вопросе я доверяю больше, чем вашему руководителю.
Ну, т.е. на выходе имеем некоторый "компромисс" между универсальностью и удобством конечного пользователя. Что-то неудобно для пальца, что-то неудобно для клавиатуры, что-то для мыши. Зато одинаково и "одинаково терпимо" для всех… Просто всем "не совсем удобно", но никаких поводов для обид — все страдают.
И вот так с "конвергенцией" каждый раз… И не только у "Майков".
А вот тут сразу две собаки зарыты:
Есть "универсальное преобразование", и есть "правильное". "Универсальное" — это когда везде одинаково с точностью до закорючки, а "правильное" — это когда по стайлгайдам самого DE. И вот тут — либо крест снимать, либо рясу в трусы не заправлять.
Всё-таки, простите за занудство: одна Java или одна платформа? Возможно, сами DE и поддерживают ровно одну IntelliJ-платформу, а платформа-то сколько систем поддерживает?
Если мы говорим про Avalonia-UI, то сравнивать его надо с IntelliJ, а она поддерживает достаточно много целевых платформ, и платформозависимого кода там достаточно много.
Если мы говорим об IDE на базе Avalonia-UI, то, простите, с таким подходом он тоже поддерживает одну целевую платформу — Avalonia-UI. Плюсом, конечно, идет специфика инструментария разработки, специфичного для платформ, но тут, уж извините, ровно с такими же сложностями сталкивается и IntelliJ — тоже тянут слой совместимости для работы с системозависимыми инструментами.
Короче, разницы особо не видно. Может, я чего-то не углядел. Может, вы мне поясните. В чём разница между кроссплатформенной, поддерживающей множество систем вашей IDE и семейством продуктов JetBrains, которые, как оказалось, не кроссплатформенные?
Сильно не заморачивайтесь, это просто комик-мем.
"Представляешь, есть 14 конкурирующих стандартов для <вставить нужное>. Необходимо срочно разработать один новый, универсальный, который объединит в себе преимущества и опыт всех имеющися" => "Работа, работа, работа" => "Представляешь, есть 15 конкурирующих стандартов для..."
Самое забавное то, что половина всего этого хозяйства родилась именно как попытка создать "универсальный, подходящий всем..." инструмент для управления пакетами.
В конечном итоге, есть apt, есть dnf, есть yum и т.д. и т.п. При этом набор умелок у них, в общем и целом, весьма сходный. Если нужен "инструмент для рядового пользователя, который не разбирается в этих ваших консолях" — без проблем, их есть уже, и при этом они, как правило, часть DE. Пусть и будут. Красивое окошко с рюшечками и кнопочками, которое по нажатию кнопочек тупо шпилить команды в нижележащий ПМ.
Сам-то нижележащий ПМ, простите, заради чего унифицировать? Даже будь формат пакетов одинаковый, установка пакета, собранного под, допустим, Fedora26 в Ubuntu12.04 — достаточно мутная затея. В конце концов, если сильно прижало, есть тот же alien, который вполне сконвертирует пакет. И, по-прежнему, это будет мутная идея.
Потому что линуксы различаются, все же, не только набором пакетов. В конце концов, пакет, собранный для F17 не стоит ставить на F26, а вы предлагаете "единый формат" запилить, и таскать между дистрибутивами?
В конце концов, есть уже "единый и универсальный формат", давно уже есть. *.tar.gz — реально универсальный, и работает везде! Зачем еще один?
Вот об этом я выше и говорил. Либо имеем некоторый API, который в линуксе обертывает DBus (к слову, не во всех этих ваших линуксах DBus есть...), а в винде, например, болтает иконкой в трее. Либо имеем две сущности: DBus(который надо дергать в Linux), и TrayIcon(который надо дергать в винде). Оба варианта рабочие, но оба два, простите, выглядят немного костыльно.
Слышал, знаю, даже периодически работаю по ТЗ. В случае нереализуемости ТЗ имею привычку сообщать об этом заказчику, прилагая варианты изменения оного до наступления полной реализуемости. Достаточно четко?)
Тут, какбы, формулировка зыбкая. ТЗ — это "техническое задание", которое предполагает наличие двух сторон процесса — принимающей ("Заказчика") и выполняющей ("Исполнителя"). И вот тут мотивация первого понятна — он получает продукт. В чём мотивация второго в свободном проекте без оплаты? В случаях самомотивации второй стороны, как мне кажется, оная сторона вполне имеет право отклонить какие-то из требований ТЗ. Или нет?
В случае же общности сторон (т.е. отсутствия ярко выраженных ролей заказчик-исполнитель), как мне кажется:
А если давший задание — упёртый балбес… Какбэ, кхм… А почему вы его лесом не послали, например? Или не сказали: "Надо? Прям никак без этого? Сделай!" Чем он вас мотивирует? Он держит ваших родственников в заложниках? Бьёт? Угрожает? Шантажирует?
Упёртый балбес, руководящий проектом, как правило, имеет печальное влияние на судьбу проекта в целом. Если разработчиков сильно более одного, и весомая часть считает руководителя неправым упёртым балбесом… Ну, форкнуться можно же?
Ну раскройте уже глаза "постановщику задачи". Ссылку на официальную документацию дайте, что ли, почитать.
Вот прямо оттуда:
Рантайм флатпака — это, условно, его /usr. В момент запуска приложения, содержимое его рантайма монтируется как /usr. Вот ровно то, что в рантайме пакета лежит, в /usr для флатпака и будет. Надо системные библиотеки? Скопируйте. Надо другие версии — положите куда требует спецификация. Не хотите класть — ищите другие инструменты.
>> А пояснение верно. Хотя замечу что Linux это не ОС, а всего лишь ядро.
>> Если претензии летят в сторону Linux, а не к прим. ArchLinux, то все претензии идут к ядру, а не к ОС(Учти этот факт).
Вот я и намекнул предыдущему оратору, что он с претензией по трею не по адресу. И, в качестве сарказма, написал, мол, трей — виновато ядро, фон рабочего стола — виновато ядро. Вы восприняли это за мое личное мнение. Это сарказм был.
>> Хмм… По поводу плиток и плиточного UI, для управления K+M они настолько же удобны как и кнопки которые не удобно тыкать пальцем если они маленькие.
>> Заголовки окон на полэкрана для XHIDPI только, а вот кнопки для XHIDPI согласен маленькие.
Все же, согласитесь, плитки таки менее удобны для клава-мышь. Не критично, но менее удобны, чем классическое меню.
Подсказка №1: объем телодвижений между соседними пунктами меню, и между плитками в разных углах экрана.
Подсказка №2: меню реализует древовидную иерархию, причем с возможностью видеть предыдущую ступень иерархии целиком. На плитках — нереализуемо. Не могу сказать, что эта самая иерархия — то, без чего совершенно невозможно обойтись, но таки штука временами удобная.
>> Не все. Что сделано по стандарту без шагов в сторону, то везде будет работать одинаково.
Имеется в виду, что везде будет работать одинаково не-нативно?
>> Если все сделано как надо, а именно чисто специфичные для UI toolkit'а функции не используются, то LnF будет везде один и тот же.
Ну, т.е. да, не нативно. Чем тогда Qt/QML не угодил? Хотя ладно, не будем вдаваться в холивары.
Короче, определиться нужно: одинаково-на-всех-платформах vs нэйтив-лук-энд-фил. Либо-либо. Вот тут нельзя сесть на 2 стула сразу.
>> Галочка, крест и круг(Есть, нет, через костыль)
Ну, т.е. вы согласны, что всю табличку заполнить галочками невозможно? Это и называется формально недостижимо.
О ДжетБрейнс
>> Они пишут свой.
О чём я и упоминал: свой с необходимым минимумом. Если хотите, MVP.
>> У них одна платформа.
В смыыыысле? Win/Lin/MacOS — одна? Или Java одна? Т.е. гуи-фреймворк поверх Xamarin/.Net, запущенный на Win/Lin/MacOS — это РАЗНЫЕ платформы, а гуи-фреймворк поверх Java, запущенный на Win/Lin/MacOS — ОДНА. Здорово живем!
>> Они пишут свою платформу, им не нужны гайдлайны.
Вот я и пытаюсь выяснить, все же: в AvaloniaUI — тот же подход «нам не нужны гайдлайны, у нас своя платформа», или таки «везде нативненько». Просто предыдущий оратор декларировал одно, а описывал совершенно другое.
>> Смысл сея цитаты был таков, что сделаем минимум для работы системы + добавим универсальный ПМ для использования его пользователем который будет ставить ему софт который ему нужен.
Знаете же историю про «14 конкурирующих стандартов»? Универсальный ПМ не взлетит. Их и так достаточно.
Так что оставьте уже базовый ПМ в покое. Логичнее сделать надстройку над базовым ПМ с рюшечками и кнопочками. Ну так есть уже. И тоже не одна штука.
>> Да в мнении есть ошибка, но мною она не может быть воспринята в принципе.
А зря.
>> Разные реализации ABI, но все равно являются пакетами как ни крути.
Ну, т.е. в тот же Debian вы можете просто пакетом положить libmusl и ничего не изменится? Какбэ, есть мнение, что у вас полсистемы отвалится. Пакет — это такая штука, которая, концептуально, не влияет на работоспособность системы в целом, и при замене на аналог не требует пересборки всей остальной системы. Ну, т.е. libc, конечно, ставится пакетом, но, как правило, это формальность. Это часть базовой системы. Хотите заменяемости libc — положите рядом еще один репозиторий целиком, собранный на новой версии libc. Странное поведение для рядового пакета, не?
>> LSB — предоставляет всего лишь стандартную базу и всё не более, а также стандарт и его реализация не есть обязательное требование.
Ну да, это всего лишь спецификация с рекомендациями на тему «чего в этих ваших линуксах должно быть». И если уж строить IDE, работающее поверх набора системных инструментов, стоит завязываться именно на подобную спецификацию, а не на мифический «Линукс». Линукс слишком неоднороден.
>> POSIX — стандарт и его реализация не есть обязательное требование.
С POSIX'ом — аналогично.
Дело в том, что если вы пишете IDE под набор каких-то системных библиотек и с учетом наличия какого-то «стандартного инструментария», вы изначально предполагаете, что он есть. А это не факт. Самое логичное — завязаться на спеку вроде LSB, или написать свою, мол, для работы нам нужно (дальше список...). Не пытайтесь реализовать сборку под ВСЕ линуксы, иначе неизбежны моменты удивления типа «как так ping'а нету???».
В конечном итоге, достижимо создание продукта под некоторое подмножество Linux-based осей, и сильно лучше будет, если это подмножество будет формализовано, желательно с указанием спецификации, что, в каком виде, каких версий и почему нужно для всего комбайна в целом.
>> Не логично, DE != GUI-Framework.
В том и проблема, что логично… DE — desktop environment, т.е. ОКРУЖЕНИЕ рабочего стола. Со своим набором look-n-feel, пользовательских паттернов, гайдлайнов и прочим. Если эти части проигнорировать, то «родным» приложение не будет выглядеть ни на одной из платформ. Т.е. будем одинаково средненько везде. Вот, допустим, изначально заточенное под винду приложение имеет менюху вверху, кнопки действий внизу под активным содержимым. Берете «как есть», переносите в окружение третьегнома… На выходе в третьегноме есть набор изначально системных приложений с право-верхним расположением кнопок и без глобального меню, и ваше — белая ворона. И так на каждую пару окружение-окружение. С линуксом сложность еще и в том, что линукс, условно, один, и все системы на его базе воспринимаются как единое целое, а между тем набор поведений, принятый в гноме, будет так же дико смотреться на KDE, как и принесенный из MacOS.
>> Претензии к GTK+, GDK и Qt слышать более логично если речь идет об GUI-Framework.
Вот тут вы что-то перепутали. В споре о гуи-фреймворках, согласен, слышать претензии к GTK+ и Qt. GDK-то при чем? Это же просто низкоуровневая библиотека примитивов, используемая как бэкенд GTK? Это же не GUI-фреймворк?
>> Пример, нарисовать balloon-notification с сообщением что компиляция завершена.
Например, для данного случая, есть 2 пути:
1. Поступить как ДжетБрейнс — реализовать нотификашки внутри окна приложения, безотносительно трея.
2. Поступить «правильным путем». Допустим, в том же Gnome используется libnotify. Отлично оповещает, к слову.
>> А про техническое задание ничего не слышали?
Допустим слышал. Так это свободный проект энтузиастов, или вы на зарплате?
>> Если в ТЗ указано что надо сделать и ещё указано что разработать это для Flatpak, а также сказано использовать системные библиотеки другой версии и при этом их нельзя бросать в Flatpak-пакет, то хочешь не хочешь но по заданию должен будешь сделать как там указано.
Надо, например, указать разработчику ТЗ на «противоречащие параграфы» этого самого ТЗ.
1. Собрать во flatpak
2. Системные библиотеки
3. «другой версии» — это отличные от тех, которые есть в системе?
4. нельзя все это хозяйство положить внутрь flatpak
Вот прям реально невыполнимо. Ну нельзя flatpak'у давать доступ к системному /usr, он именно с этой целью и делался, чтобы у него туда доступа не было!
Ну и вообще, как-то странно звучит «использовать системные библиотеки другой версии». Это, в смысле, такие же, как в базовой системе, но другой версии? А почему же не положить их в SDK-пакет? Просто «хотелка» постановщика задач? А почему ему никто не сказал, что так не делается?
Проследите, пожалуйста, историю дискуссии, если не лень. Дело в том, что я как раз был противником позиции «виноват линукс».
Предыдущий оратор из ПРОТИВОПОЛОЖНОГО лагеря выдвинул сентенцию «Из вашего Линукса вон системный трей выпилили!» Ну неправда же! Не выпиливали! Поясню: в Линуксе как таковом системного трея никогда и НЕ БЫЛО. В ТретьеГноме был, факт. Уродливый и неюзабельный. Да, выпилили. А в KDE, например, оставили. НО… Оба этих факта к Линуксу как таковому отношение имеют весьма и весьма опосредованное. Пляски с треем — это ГномоПроблемы. Не мешайте их с ЛинуксоПроблемами — их и без ГномоПроблем хватает.
Теперь о моей поизции по UI-тулкиту. Видимо, надо обосновать:
а) слабореализуемо
т.к. каждая платформа имеет свой набор поведений, инструментов, best-practices и т.д. и т.п. Что-то универсальное… Хм, как бы, пробовали уже. Canonical пробовал, Microsoft пробовал. «Конвергенция» не взлетает. На выходе мы имеем «плитки», в которые удобно тыкать пальцем, но чудовищные с точки зрения управления мышью и, уж тем более, клавиатуры. Мы имеем заголовки окон в полэкрана на десктопе, и имеем кнопки 15х15px на смартфонах, в которые вы хрен пальцем попадете. Все универсальное заведомо хуже нативного.
б) расходится с политикой поставщиков ОС
Гайдлайны у каждого свои. И даже можно оформить темы, чтобы оно «нативно выглядело» на каждой платформе. При этом есть еще UX и набор паттернов поведения, которые автоматически не сконвертируешь. Ну вот никак, реально. Все равно придется платформо-зависимую часть пилить, хоть убейся. Или забить просто на native-look-and-feel… Но тогда о какой «полноценной поддержке» можно говорить?
в) формально недостижимо
Вот составьте табличку умелок и проставьте галочки, на каких платформах что реализовано. Вот прямо на пункте «значки в трее» ваша затея и поутихнет. Где-то они есть, где-то не предусмотрены, а где-то плагинами (вы тут плюс или минус ставить будете?) Короче, никогда у вас вся табличка плюсами не будет заполнена, т.е. ФОРМАЛЬНО НЕДОСТИЖИМО.
Если говорить про JetBrains, то эти ребята не пытаются взять «универсальный кросплатформенный гуи-фреймворк» и на нем реализовать. Они запилили «необходимый минимум» под нужные им платформы, и ничего, норм, живут. При этом запускаются они далеко не под каждым линуксом, например. И не пытаются запилить версию своих DE под мобильные платформы, зная, что они там на фиг не сдались. Да и по поддержке гайдлайнов они не заморачиваются. Одинаково кладут болт на гайды всех платформ, на которых работают.
>> Знаешь подвижки в плане «создадим единую пакетную систему для всех Linux-kernel based систем» рано или поздно должны быть.
Вот это тоже не выстрелит. Были уже попытки. Вполне обоснованно не взлетели. Кто-то придерживается политики «ставим только то, что необходимо», и его пакетный менеджер ведет разветвленное дерево зависимостей, а в пакетах тонны метаинформации на тему что-от-чего-зависит-и-в-каком-порядке-ставить. Кто-то придерживается более утилитарно-интерпрайзного подхода вида «винты дешевые, чо мы паримся», и вот он с икренним недоумением смотрит в количество метаинформации в пакетах первых. А третий вообще все это пытается в 2-гигабайтную SD-карточку упихать, для него кретинами выглядят и те, и другие. Есть, вероятно, «золотая середина», которая будет одинаково неудобна всем. Но зачем?
>> А дисты Linux если и имеют различия то только в пакетной составляющей.
А вот это уже совсем ошибочное мнение, извините за прямоту. Начать с того, что есть, например glibc. А есть еще libmusl, а есть eglibc. А еще есть AppArmor vs SELinux. А кроме пакетных менеджеров есть еще и инит… А еще не то LSB, даже POSIX не все дистрибутивы поддерживают…
Так что, дорогой мой созидатель, пожалуйста, не смешивайте проблемы Linux'а и проблемы DE. Винду, например, можно за гуй ругать — они, по сути, неотделимы друг от друга. В Линухе, исторически так сложилось, мухи отдельно, котлеты отдельно.
Поэтому со стороны разработки ГУИ-фреймворка логично слышать претензии к Гному, к КДЕ, к ТысячиИх. Ругать Линуху за заскоки гнома — странное занятие.
С точки же зрения IDE, т.е. разработческой платформы — тут да, вопросы, вероятно, больше к Linux'у, но среди этих вопросов уж точно нет «ой, трей отпилили». Не представляю, если честно, зачем реально IDE иконка в систрее.
Ну а про «нужны именно системные библиотеки» — нафига тогда во flatpak пихать, если системные нужны? А если уж прижало именно во flatpak — ну, скопируйте системные вовнутрь, в чем, собственно, проблема?
Только, ради всего святого, не выдавайте такое поведение за норму. «Для запуска нашего софта под андроид, необходимо рутануть устройство» — это НЕ нормально.
А по сути ваших задач, мнение мое следующее:
1. Кросплатформенный UI-тулкит — это, конечно, хорошо, но:
а) слабореализуемо
б) расходится с политикой поставщиков ОС
в) формально недостижимо
2. IDE на базе кросплатформенного UI-тулкита… Какбэ, в некоторых случаях кроссплатформенность IDE идет только во вред.
3. Выбор для реализации этого проекта неполноценно кроссплатформенного .NET — тем более странно. У вас внутри наполовину Mono, наполовину .NetCore. При этом все это в стадии жесточайшей беты и ваще жесть.
4. Для разработки под встраиваемые железки песочная изоляция — самое оно. Внутри песочницы вы будете иметь ровно те заголовочные файлы, версии библиотек и прочую кашу, которые будут доступны вам на целевой системе. Гарантия того, что где-то не просочится десктопный инклюд с вашей девелоперской машины — это только к лучшему. Еще раз повторю, для сборки под целевую платформу лучше иметь весь рантайм + исходники/либы платформы внутри песочницы, чтобы потом не удивляться, почему «а на моей машине работает».
5. Претензия по поводу пакетов для Linux — она из рода «я под винду собрал, а на макоси не запускается! Оказывается, пересобирать надо! Как так?» Дистрибутивы линухи различаются между собой примерно как Windows и Android. Поэтому претензия к «жопа собрать один пакет под линукс» — она странная. Вы же не сетуете, что у вас один бинарник под виндой и под макосью не запускается. Просто перестаньте поддерживать «Linux». Нету никакого «Linux'а», есть Ubuntu отдельно, Fedora/RH отдельно, Suse, Arch — тысячи их. Поддерживайте целевую платформу, а не зоопарк целевых платформ. Или отказывайтесь от поддержки целиком, если процент пользователей там не критичен. Даже доведи разрабы flatpack до совершенства, до полной усраться-совместимости c миллионом дистрибутивов Linux, вот реально оно на том же Alpine не заведется, и на тысяче других. Потому что они принципиально про другое.
6. Ну а последний абзац — он вообще про Xamarin-проблемы. Т.е. Xamarin-овцы упаковали во флетпак — виновата, естественно, Linux-экосистема. У вас были проблемы с разработкой на Mono под Linux — проблема Linux-экосистемы… Короче, при всех раскладах виноват именно Linux, причем в целом.
Давайте конкретизировать претензии и ограничивать аппетиты.
А кто-то говорил про Android SDK?
Вот ЭТО вы просили, и да, ОНО дистроспецифичное.
А с точки зрения компилятора — недостаточно. Надо еще, чтобы версии библиотек внутри песочницы совпали с версиями снаружи, например. И это превращает весь механизм в пшик, никому не нужный и не работающий.
Ну вот неправда же ваша. Предлагается делать поддержку под SDK той версии, которая во flatpak'е или snap'е. Понимаете? Именно под ту версию, которая в базовом лейере пакета. Т.е. прямо так и говорят: не заморачивайтесь со спецификой различных дистрибутивов, пишите под ваш образ! А уж он будет работать на всех дистрибутивах — это уже наш головняк.
Ну вот это и логично же. Макось — это коммерческая ось, направление развития которой курирует вполне себе конкретная фирма, и конкретные люди. И, если эти люди договорились между собой, что библиотека Икс во всех продуктах будет версии Игрек с версией билда Зет, она там будет. А в линуксе не договорятся.
Поэтому от системных библиотек вас изолируют, и правильно делают.
Нету тут религии, сугубо техническое решение.
Зачем вообще этот уровень абстракции, если вам нужен доступ к дистроспецифичным вещам? Нужны дистроспецифичные вещи — пишите под конкретный дистрибутив.
В пример вы приводите Винду, в которой ситуация, вроде как, устаканилась. Ок, только вcя разница в том, что винда одна, а линуксов — море.
Хотите windows-way? В чем проблема, определитесь с конкретным дистрибутивом, который будете поддерживать. Получится стабильно и со своей спецификой.
Хотите, чтобы работало на всем зоопарке линуксов? Суйте приложение в песочницу-абстракцию и не выпендривайтесь.
Собственно, именно это и предлагается. Всё, что тебе нужно, носи в своем снапе. Что не так?
В /opt до сих пор никто не запрещает таскать, например. Да и chroot не вчера придумали…
Странно обвинять песочницу в том, что она песочница.
Согласно логике песочницы — принести GNU Make с собой, нужной версии. Иначе опять начнется «у вас патроны не той системы». Make, autotools и прочее, например, рекомендуют так: github.com/snapcore/snapcraft/blob/master/demos/libpipeline/snap/snapcraft.yaml
В сценарии, заради которого все затевалось, системный /usr/include читать и не надо. Читать надо тот, который для этой песочницы специальный.
Понимаете, философия в том, что относительно стабилен линукс ровно по линии glibc. В ядре — нестабильное ABI, заради развития. В юзерспейсе — вообще форменный угар и содомия. Единственное решение — в песочницу положить все от glibc и выше в сторону юзерспейса. Т.е. и gtk у вас там свой будет, фиксированной версии, и всяческие lib*.*.*.so. Вот именно так гарантируется, что тот же фотошоп не отвалится при обновлении из-за того, что в гноме вылилят DBus, а Gentoo перейдет на BusyBox (так, навскидку, в порядке бреда).
Если вы делаете IDE для разработки приложения-под-песочницу — все норм. У этого IDE прям ровно нужные /usr/include и версии конпеляторов будут. Если общесистемное IDE — вы опять не по адресу. Оно заради пользовательского софта пишется.
Вот именно, что дома не сервер. Поэтому основной вопрос к фронту таки. Поверьте, в браузерном исполнении он будет тормозить сильнее, чем бэк.
Концепция, очевидно. Flatpak — песочница для сторонних (3rd party) пользовательских приложений. Нравится это или нет — с этим придется смириться. Для различных фоторедакторов, книг рецептов и прочих веселых ферм — самое оно. Вот реально не надо им доступ за пределы «хомяка».
Если вы системный софт в него пытаетесь запаковать… Ну, видимо, вы используете flatpak не по назначению. Он не плохой, он просто для этого не предназначен.
Snap, к слову, тоже не совсем ваш use-case. Devmode — это режим отладки приложения, не предназначенный для боевого применения, однако. Собственно, запретить вам пользовать devmode в своем проде никто не запретит, но широкого применения данная модель не предполагает.
Другое дело — плагины. Всё, к чему вам изнутри песочницы доступ нужно иметь, вы можете положить в плагин, а потом присобачить к вашему приложению (в случае со snap). Это, типа, «кошерный» путь применения.
Собственно, так сделать, особо, никто не мешает. И даже будет работать примерно в 50% случаев. Нужно, буквально, D-Bus и установщик, который на нем висит. Т.е. реализуемо, например, в Ubuntu или Fedora. Однако «правильный путь» — всобачить то, от чего зависит ваш пак, в зависимости этого самого пака и поставить отдельным слоем.
Собственно, подача про osX и win — ну… какбэ там тоже лютейший и корявейший костыль, например…
На выходе 3 проблемы:
1. Упаковать «как есть» веб-приложение и выдать его за десктопное… Тормозить будет люто. Да и смысл? Чем будет отличаться от гуглосервиса?
2. Даже переписать фронт, избавиться от промежуточного REST'а… И для офиса вертеть на своей машинке базу данных? Оно реально надо?
3. Переписать фронт, переписать бек… Т.е. «переписать все»? А зачем тогда исходники гугла?
В данный момент ситуация, скорее, патовая, и навешивание ярлыков «прав», «не прав», «фанатик» и «религиозные убеждения» ничего не изменит и мир, тем более, не спасет.
Есть конкретная группа людей, которая «пилит» ядро Linux. Они, что логично, определяют то, как ядро должно работать, и какие его части для чего предназначены.
Есть Nvidia, которая, по вполне очевидным причинам, в модель, данную разработчиками ядра, «ложиться» не хочет. Для того, чтобы заработало «как задумано», нужно предоставить спецификации.
Учитывая открытую модель разработки ядра, спецификации придется предоставить в открытый доступ, т.е. всем желающим. Открытые же спецификации позволят «разлочить» некоторый функционал на более бюджетных моделят видеокарт Nvidia, что неизбежно уронит покупки более дорогих девайсов.
Т.е., с одной стороны, есть совершенно четкие и определенные спецификации, которые гарантируют корректную работу драйвера при соответствии API, и нежелание разработчиков ядра положить болт на свои спеки мало того, что понятно, так еще и похвально. При этом есть нежелание Nvidia урезать свои доходы, которое не менее понятно, но, в данном контексте, значительно менее похвально.
Почему такой попы нет на Windows/osX? Также совершенно очевидно. Обе системы закрыты, т.е. спецификации не «утекут». На предоставлении спецификаций производителям проприетарных систем Nvidia не теряет в доходах.
В данном контексте первые — весьма достойные люди безо всяких «хотя бы за». Право вторых же «не любить первых» весьма сомнительно. В конце концов, проблема создана не на ровном месте, а по вполне объективным причинам. Так что вторым можно порекомендовать, скорее, отказаться от продукции Nvidia в пользу Intel/AMD. Нет, не потому, что Nvidia плохая или что-то подобное, а потому, что, по объективным причинам, реализовать корректную работу вышеозначенной продукции в рамках Linux не представляется возможным. Если же корректная работа Nvidia-девайса более приоритетна, чем операционная система, может быть, вторым просто поменять ОС?
Вот тут то, как раз, загадки нет. Flatpak делался, по сути, как реализация модели распространения приложений по типу Android'ной. Т.е. вся философия в том, чтобы не тащить уйму непонятно кем написанного гамна разной степени корявости в репозиторий системы. А вот этому гумну, как раз, изоляция не помешает.
Собственно, это зачатки аналога Play/Appstore под линуху. Логическая цепочка, как раз, очевидна: Унификация платформы -> Способ монетизации -> Появление тучи софта разной степени корявости -> Увеличение пользовательской базы -> Подтягивание A-class софта -> «Причесывание» магазина приложений.
Собственно, именно то, что Google сделал с Android. В принципе, вполне может выстрелить.
И да, как «коробка» для эмуляторов терминалов и системного софта оно не задумывалось от слова «совсем». А пользовательские «ништяки», типа клиентов всяких «одноклассников», «вайцапов» и «веселых ферм» туда вполне себе ложатся.
Для «условно-систеного» же софта… Ну, тут, собственно, какфсигда, 2 пути. Либо щупайте snap (благо, поддержку теперь и Redhat условно анонсировал) — у него умелок побольше, либо пилите пакет для системы. Собственно, вызов консольной тулзы по имени в сценарий «песочницы для гарантированной совместимости» и не укладывается. В нижележащей системе консольной тулзы, которую вы вызываете, может и не оказаться. Это уже дистроспецифичная вещь — т.е., в некоторых случах может не сработать. Короче, вполне предсказуемая и даже логичная модель «жрите, что дают, если надо еще — заказывайте у шеф-повара».