LINUX.ORG.RU

Какой вектор развития дистрибуции и пакетирования пользовательских программ вы считаете наиболее интересным и/или перспективным

 


0

1

В скобочках приведены примеры, чтобы лучше понимать суть.

  1. Пакетные менеджеры с поддержкой установки различных версий пакетов (nix) 177 (42%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Кроссдистрибутивные системы управления пакетами (flatpak) 113 (27%)

    ************************************************************************************************************************************************************************************************************

  3. Создание пакетов "всё-в-одном" (appimage) 110 (26%)

    ******************************************************************************************************************************************************************************************************

  4. Использование статической линковки для достижения кроссдистрибутивности 79 (19%)

    **********************************************************************************************************************************************

  5. Другой 67 (16%)

    *************************************************************************************************************************

  6. BSD (порты FreeBSD) 56 (13%)

    *****************************************************************************************************

  7. Кроссплатформенные веб-приложения (PWA, wasm) 54 (13%)

    *************************************************************************************************

Всего голосов: 656, всего проголосовавших: 426

★★★

Проверено: Satori ()
Последнее исправление: fernandos (всего исправлений: 3)

Ответ на: комментарий от James_Holden

надо

Никому не надо. Flatpak — это игровая песочница над OSTree. Stable API — nonsense. И всё такое.

Это и не столь даже плохо (не держаться за stable api). Можно приводить в пример ту же macOS, где вообще на и выкинули 32 битные приложения к примеру. В линуксах вон идут к этому ещё и долго…

Но суть, что бизнес модель направлена на тестовый полигон, а не про домашней десктоп. Этак с голой задницей берём серьёзные технологии и с палками и смолой делаем криво-косо десктоп минимальными ресурсами.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 2)
Ответ на: комментарий от mord0d

Пакеты всё-в-одном вначале появились в Mac OS X (на тот момент ещё не macOS)

Да ну! А как же NeXTSTEP? А ещё можно посмотреть на RISC OS, там приложения в директориях с названиями вида "!Имя", которая отображается в менеджере файлов как приложение и при клике запускает его. Кстати, ещё вопрос, где это раньше появилось, в NeXTSTEP или в RISC OS. Тот же dock сначала появился в RISC OS, потом его сделали в NeXTSTEP, и только затем он появился в Mac OS X. При этом в Mac OS Classic его никогда не было.

ls-h ★★★★★
()
Ответ на: комментарий от fernandos

Только снап.

Ну а в Flatpak монтируются директории. Точнее, там создаётся пространство имён отдельное и потом монтируется. В контексте данного разговора не важно, образ файловой системы там или директория. В обоих случаях все содержащиеся внутри файлы не раскидываются по всей системе, а лежат отдельно.

ls-h ★★★★★
()
Ответ на: комментарий от James_Holden

Во-первых очевидно что это фуфло никому, не только шапке

Что же в .deb принципиально плохого? Это ведь просто, можно сказать, архив с дополнительной информацией.

ls-h ★★★★★
()
Ответ на: комментарий от pingvinek

Бинарные пакеты (в том числе собранные из портов) устанавливаются в /usr/local. Но единая система распространения не означает неразделимость с базовой ОС.

Это в Linux весь софт валится в /, и отделить некое подобие базовой системы (которой в Linux фактически нет) от опциональных пакетов в принципе невозможно.

mord0d ★★★★★
()
Ответ на: комментарий от James_Holden

Нет как раз, там внутри песочницы все практически стандартно.

Разве? Во Flatpak оно лежит внутри /app

ls-h ★★★★★
()
Ответ на: комментарий от ls-h

Они там технически были устроены иначе. Именно в том виде, как они выглядят сейчас (Flatpak, Snap, AppImage) вначале появились именно в MacOS.

mord0d ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Где вариант «классические ПМ»?

Мне больше нравятся классические ТТ, у них и калибр больше, и пробивная способность. И носить их удобнее.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Именно в том виде, как они выглядят сейчас (Flatpak, Snap, AppImage) вначале появились именно в MacOS.

AppImage ещё куда не шло. А Flatpak и SNAP — совсем нет.

fornlr ★★★★★
()

А почему BSD противопоставлен линуксам? Source-based пакетные системы (freebsd ports, openbsd ports, pkgsrc, portage, arch, kiss, slackware, nix) ничем между собой кардинально не отличаются.

Будущее конечно же за ними.

slovazap ★★★★★
()
Ответ на: комментарий от James_Holden

Но!!!!! Для пользовательской системы это не подходит.

Кто это сказал? Пользователи, которые всю жизнь просидели на Windows и Mac OS (именно в таком написании, т.к. с классики и пошёл принцип одно приложение == один файл). Почему на GNU/Linux и подобных *nix системах обязательно нужно следовать этому принципу? Кроме прочего GNU/Linux, чаще всего, это свободная и открытая ОС. А это на мой взгляд отличный повод для более тесной интеграции приложений. Которой почему-то не наблюдается. Если вспомнить начало развития Windows и Mac OS, то что там было? Приложения продаются за деньги в больших картонных коробках, полностью проприетарные. И пользователь приобретает отдельное приложение-коробку. Конечно, приложение не должно рассчитывать на то, что оно сможет опереться на функции из другого, можно только на систему. Тем более, если речь про конкурирующие приложение из той же категории. Вот документ Adobe Photoshop без всяких проблем интегрируется в Adobe Illustrator (и в обратную сторону тоже работает). А как насчёт вставки CorelDRAW внутрь документа Adobe Photoshop? Чтобы к нему можно было применить какие-то эффекты, обновить внутри CorelDRAW, и все изменения отобразились в Adobe Photoshop с обновлёнными эффектами. Этого нет и не будет, т.к. это разные конкурирующие продукты.

На GNU/Linux подавляющий процент ПО открытый и свободный. Он может и должен интегрироваться друг с другом. Однако, если я в GIMP перетяну svg документ, то он будет просто растрирован и как вектор его уже отредактировать не получится. Да, это вообще не про пакетные менеджеры уже. Но, может быть так именно потому, что и в GNU/Linux мы говорим о приложениях, а не о функциях.

А пользователи? Разве их волнуют приложения? В первую очередь их волнуют документы, работают они с документами. При этом приложение это инструмент. И функция (в том смысле, как ты описал в своём сообщении) это тоже инструмент. Только получается, что функции это более мелкие и более точные инструменты, а приложения - более большие. Вот я как пользователь делаю табурет. У меня есть два приложения. Первое делает квадратное сидение и четыре ножки с перекладинами. Второе делает круглое сидение и четыре ножки без перекладин. Как мне сделать круглое и с перекладинами? При работе с функциями, которые совместимы друг с другом, это кажется гораздо более реальным.

Изначально в Unix всё так было. Единственной проблемой было то, что всё через текст. Точнее говоря, тогда это не было проблемой. А вот сейчас - да. Сейчас GNU/Linux хорошо бы развиваться в сторону ухода от текста, к единым объектно-ориентированным стандартам. Правда этого не наблюдается. Разве что D-Bus, который довольно неудобный, «приделанный сбоку» и слишком многословный.

В общем, надо менять пользователей, чтобы они думали иначе. Да, систему тоже надо менять, но совсем не в сторону Windows или (ужас-ужас) macOS, где всё за пользователя решает Apple и из настроек 3 кнопки.

ls-h ★★★★★
()
Ответ на: комментарий от James_Holden

хитрый никсовый путь к библиотеке

Как это выглядит?

ls-h ★★★★★
()

Формат дистрибуции PBI из PC-BSD старых версий. Удобно - все библиотеки, от которых зависит работа приложения, распространяются в одном архиве и устанавливаются в один каталог с приложением - легко изолировать в случае каких-то проблем.

iZEN ★★★★★
()
Ответ на: комментарий от ls-h

А как насчёт вставки CorelDRAW внутрь документа Adobe Photoshop? Чтобы к нему можно было применить какие-то эффекты, обновить внутри CorelDRAW, и все изменения отобразились в Adobe Photoshop с обновлёнными эффектами. Этого нет и не будет, т.к. это разные конкурирующие продукты.

Да ну не может такого быть. Всё прекрасно стыкуется на уровне OLE-контейнеров. И «редактирование по месту» должно работать, если все необходимые продукты установлены.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Да ну не может такого быть.

Мне сейчас не на чем попробовать. Насколько я помню, перетаскивание .cdr файла в окно с открытым .psd приводило к сообщению «Неизвестный формат». Попробуй, если есть на чём.

ls-h ★★★★★
()
Последнее исправление: ls-h (всего исправлений: 1)

тот случай, когда все и везде плохо

kott ★★★★★
()
Ответ на: комментарий от ls-h

Пользователи, которые всю жизнь просидели на Windows и Mac OS (именно в таком написании, т.к. с классики и пошёл принцип одно приложение == один файл).

Да как-то нет.

Простые и общие форматы — они общие. А сложные и мощные монстры понятно дело, что специфичные. Так везде.

fornlr ★★★★★
()
Ответ на: комментарий от ls-h

Для «перетянуть» умные люди придумали OLE.

Radjah ★★★★★
()

flatpak - это ж по-сути то ж самое, что в винде когда с любой программой набор dll’ок идет

tz4678 ★★
()
Ответ на: комментарий от mord0d

и отделить некое подобие базовой системы

А что под этим подразумевается? Можно же пакетным менеджером удалить всё то, что не базовая система, например. Или просто узнать, какому пакету принадлежит каждый файл. Что плохого, что системный исполняемый файл и исполняемый файл какого-то приложения лежат в одной директории /usr/bin? Чем принципиально лучше, если от приложения будет в /usr/local/bin? Ведь в любом случае никто не предлагает эти файлы руками раскладывать или удалять.

ls-h ★★★★★
()
Последнее исправление: ls-h (всего исправлений: 2)
Ответ на: комментарий от iZEN

Формат дистрибуции PBI из PC-BSD старых версий.

Это ведь тоже самое, что и AppImage?

ls-h ★★★★★
()
Ответ на: комментарий от ls-h

Почему на GNU/Linux и подобных *nix системах обязательно нужно следовать этому принципу?

Потому что он не какой-то особенный. Десктоп он и в африке десктоп, это - задача, и она имеет вот такое решение.

А как насчёт вставки CorelDRAW внутрь документа Adobe Photoshop?

В винде для этого целая подсистема OLE есть. Технически куски проприетарных приложений друг в друга там встраиваются без проблем. Но это нужно специально обеспечивать в коде обоих приложений.

Однако, если я в GIMP перетяну svg документ, то он будет просто растрирован и как вектор его уже отредактировать не получится.

Ты хоть в целом представляешь технические сложности реализации этого на линуксе?

Это можно сделать, но есть ряд проблем. Нужен аналог виндового OLE.

В первую очередь их волнуют документы, работают они с документами. При этом приложение это инструмент. И функция (в том смысле, как ты описал в своём сообщении) это тоже инструмент. Только получается, что функции это более мелкие и более точные инструменты, а приложения - более большие.

Интересная мысль. Только - приложения это не более большой инструмент, это инструмент, который сразу делает прикладную задачу, целиком. Бумц - и вылетает табурет. Сразу.

Изначально в Unix всё так было. Единственной проблемой было то, что всё через текст.

Нет нет нет. Еще раз. Проблема не в этом.

Посмотри на это с такой стороны.

Юникс это среда программирования (как Python с его экосистемой). Есть основной скриптовый язык shell, для него можно писать функции на нем самом или на C. Ну все как в питоне.

Но - в питоне функции обмениваются объектами, а не текстом. А так все то же самое. То есть питон - это современный объектный «юникс». И ничего тут изобретать не надо.

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

James_Holden ★★★
()
Ответ на: комментарий от ls-h

А что под этим подразумевается?

Софт из пакетов/портов никогда не лезет за пределы /usr/local (за редким исключением оно может срать в /var). Это значит что установив заведомо сломанный, например, ncurses, ты сломаешь весь софт его юзающий, кроме того что из базовой системы, а просто удалив сломанный пакет ты получишь полностью рабочую систему, которая будет загружаться и работать. Даже если ты сломаешь базу данных менеджера пакетов, ты можешь просто удалить /usr/local, поставить всё заново. Не взаимодействуя с системными компонентами ты не можешь их сломать кривыми ручонками.

В Linux, если прилетело мажорное обновление glibc, а остальной софт (это ведь всё разные пакеты, и мейнтейнеры у них разные) за ней не успел, он превращается в тыкву. В FreeBSD базовая система консистентна, база пакетов консистентна с базовой системой, но пакеты не требуются для работы базовой системы (можно даже обойтись одной только базовой системой, она вполне самодостаточна).

Исходя из этого, FreeBSD до сих пор может грузиться по сети (PXE) и прекрасно работать, развёртывание пакетов может быть организовано для каждой группы хостов и тоже распространяться по NFS в read-only, а домашние директории уже на клиентах (или тоже по NFS, тогда можно иметь клиенты вообще без дисков). Админы группы хостов имеют доступ только к пакетам своей группы, и сломать базовую систему (общую для целой архитектуры) никак не могут.

mord0d ★★★★★
()
Ответ на: комментарий от James_Holden

это - задача, и она имеет вот такое решение.

Опять же, почему только такое? Потому, что пользователи Windows так привыкли?

Ты хоть в целом представляешь технические сложности реализации этого на линуксе?

Я не в курсе устройства формата файлов GIMP, не знаю, можно ли туда что-то положить кроме растровой информации. Связывание отдельных файлов реализовать достаточно просто, можно за ним следить через inotify.

Нужен аналог виндового OLE.

Вот я и говорю, что надо единый стандарт для этого.

Но - в питоне функции обмениваются объектами, а не текстом.

Так и надо. Только в удобном виде, чтобы это было легко писать в интерактивном формате командного интерпретатора. И чтобы обмен данными между «функциями» был и между разными процессами и вне зависимости от используемого языка. Т.е. если мы смотрим на командный интерпретатор как на среду программирования, на утилиты как на функции, то мы получаем функции которые принимают только текст и отдают только текст. Зато они могут быть написаны на разных языках и выполняться не только в одном процессе самого интерпретатора, но и в разных, в том числе параллельно.

И ничего тут изобретать не надо.
Один Python полностью заменяет весь юникс-вей.

Для него есть огромное количество библиотек, но они не покрывают все те задачи, что утилиты командной строки. Могу ли я управлять пользователями из Python'а? Вполне вероятно, что такая библиотека есть, даже несколько. Но оно всё равно будет работать через костыли, т.к. где-то внутри парсить текст. Я же говорю о базовом формате для взаимодействия различных компонентов. Т.е. чтобы его можно было передавать от любой утилиты к любой, как сейчас текст через пайп.

Как пример, можно вспомнить всем известный геморрой в bash скриптах, именно из-за того, что всё есть текст. Например, если надо перебрать какие-то файлы, а в именах есть пробелы (ещё забавнее, если там есть "-"), то надо везде всё заэкранировать, иначе всё сломается самым страшным образом.

Кроме того, есть проблема в разделении CLI и GUI. Первый обязательно сейчас ассоциирован с текстом. Хотя команда это не обязательно текст. Даже наоборот, она и не должна им быть. Почему-то все решили, что когда графический интерфейс отдельно, а командный отдельно, то так и должно быть. Но так быть не должно. Например:

ls photos-dir/*.jpg | filter color_mode == CMYK | filter same_face_as='another-photos-dir/my-friend-petya.jpg' | show thumbnails

Т.е. должна быть возможность показать результат работы команд в некотором графическом представлении. Да, это можно сделать и сейчас. Можно написать скрипт, который, например насоздаёт символьных ссылок на результаты работы фильтра. Но это костыль. Гораздо удобнее было было передать список объектов дальше по цепочке так, чтобы его могло прочитать любое приложение и не возникло бы никаких проблем с тем, что там написано в именах, как именно разделяются имена файлов друг от друга и т.п.

Текст вообще это зло. Например, в GNU/Linux не должно быть /etc но должен быть свой аналог реестра. Да, я догадываюсь, что сейчас юниксоиды могут начать закидывать меня помидорами. Но необязательно переносить все недостатки из Windows. Это может быть множество файлов, а не парочка больших, можно сделать описание параметров, их базовую проверку (диапазоны и списки возможных значений). Комментарии при этом тоже никуда не денутся. И аргумент «текст можно отредактировать чем угодно» не совсем правильный. Текст крайне неудобно редактировать без текстового редактора. Да, они есть везде, но так же везде бы были и средства работы с реестром.

ls-h ★★★★★
()
Ответ на: комментарий от fornlr

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от ls-h

Потому, что пользователи Windows так привыкли?

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

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

Зато они могут быть написаны на разных языках

Не могут. Объекты между разными языками работать не будут. Придется их сериализировать, например в JSON, и парсить с другого конца опять в объект. То есть от текста никуда не деться.

Почему-то все решили, что когда графический интерфейс отдельно, а командный отдельно, то так и должно быть.

Это не так решили, а иначе ты не сделаешь.

Пайп это линейная последовательность фильтров. Утилита запускается, получает входные данные, обрабатывает, пишет в stdout выходные. Все.

Любая графическая программа предполагает совершенно другой принцип работы - она запускается, постоянно висит в памяти, в цикле обрабатывая события от устройств ввода. Этот принцип несовместим с линейной и неинтерактивной логикой работы пайпов.

А если ты хочешь через пайп картинку по фильтрам гонять - это и сейчас легко сделать, только придется картинку сериализировать в текст и обратно на каждом «скачке».

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

Например, в GNU/Linux не должно быть /etc но должен быть свой аналог реестра

Это можно сделать, но вряд ли даст слишком большую пользу. Хотя это можно обсуждать.

James_Holden ★★★
()
Ответ на: комментарий от James_Holden

Они не привыкали. Windows изначально таким и был.

Может быть я неточно выразился. Я говорил о том, что пользователи Windows привыкли к устройству Windows, т.к. собственно всегда таким оно и было. Но из этого не следует, что в других ОС надо подстраиваться под них.

Зато они могут быть написаны на разных языках

Не могут.

В смысле, сейчас утилиты (программы) командной строки могут быть написаны на разных языках.

Объекты между разными языками работать не будут. Придется их сериализировать, например в JSON, и парсить с другого конца опять в объект. То есть от текста никуда не деться.

Не обязательно же JSON. И форматы бывают не только текстовые. Сеарилизовать - да, обязательно. А как без сериализации можно организовать тот же пайп? Я уточню. Когда я говорил «текст», я в первую очередь подразумевал плохую структуру, точнее почти полное её отсутствие. Т.е. между утилитами передаётся текст, о значении которого надо «догадываться», можно только предполагать, что значения разделяются пробелом (не только им, но как правило) и это работает не всегда. JSON хоть и текстовый формат, но уже гораздо лучше того, что сейчас передаётся, т.к. имеет чёткую структуру. Но можно выбрать или создать бинарный формат. Его разбор на той стороне пайпа будет более эффективен в сравнении с JSON'ом и просто текстом. В общем, строго говоря, речь у меня была о передаче сериализованного объекта.

Этот принцип несовместим с линейной и неинтерактивной логикой работы пайпов.

Ну почему же? Я же привёл пример, где цепочку из команд завершает графическая утилита.

А если ты хочешь через пайп картинку по фильтрам гонять - это и сейчас легко сделать, только придется картинку сериализировать в текст и обратно на каждом «скачке».

Извини, но тут написана какая-то ерунда. Сам по себе пайп никаких ограничений на то, что там передаётся не накладывает. Можно же через dd читать /dev/random и отдавать его на упаковку в gzip. Соответственно, чтобы просто передать картинку от одной утилиты к другой, её в текст превращать не надо. Допустим, есть она в JPEG формате, в нём и пойдёт по цепочке. А может быть и просто raw поток пикселей. Я говорил о тексте в том смысле, что выдаётся стандартными утилитами командной строки, всякие ls, find, т.п.

ls-h ★★★★★
()
Ответ на: комментарий от intelfx

Так багтрекеры открыты - можно найти и посмотреть. И это практика, а не теория. Какой вектор развития дистрибуции и пакетирования пользовательских программ вы считаете наиболее интересным и/или перспективным (комментарий)

И самому можно попытаться поставить старые пакеты с flatpak (это просто, если глаза красные).

Так что так. А выдернуть как-то библиотеки и само приложение из контекста не имеет смысла – это сферическая и нереальная ситуация.

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 5)
Ответ на: комментарий от ls-h

Но из этого не следует, что в других ОС надо подстраиваться под них.

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

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

Эти же пайпы и утилиты не на пустом месте возникли. Это весьма логичное построение системы с точки зрения потребностей программиста. В этом и проблема - программиста, не пользователя. Пользователю нужны готовые решения, он просто не станет осиливать приемы комбинирования утилит в те же пайпы.

Поэтому ОС конечно может быть и не такой как винда, но - десктопная ОС должна быть такой. Никуда от этого не деться.

Теперь тут надо выбрать - мы за линукс как он был, или мы за десктоп. И тут мнения сильно разделяются.

Сеарилизовать - да, обязательно.

Вот это и плохо, в идеале надо бы кидать просто объекты как есть. А это не получится. Я это имел в виду.

Но можно выбрать или создать бинарный формат

Тут будет очень сложно договориться.

Я же привёл пример, где цепочку из команд завершает графическая утилита

Если она в конце, то да, можно, грубо говоря отфильтрованную картинку запулить в GIMP и потом уже работать вручную. Но это не универсально - если я в середине пайпа GUI программу всуну? Как с этим быть?

Извини, но тут написана какая-то ерунда

Да, тут я не прав. Конечно можно гонять ее как есть.

James_Holden ★★★
()
Ответ на: комментарий от fornlr

Ты хочешь сказать, что сам флатпак несовместим со старыми рантаймами? Это интересное заявление. Есть какие-то ссылки?

intelfx ★★★★★
()

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

Вот это точно не избыточно

Всё остальное

А вот собрать один раз для всего это избыточно. Так и запишем.

James_Holden ★★★
()

Классические ПМ для базовой системы + flatpak для прикладных приложений. Правда для этого надо ещё решить ряд проблем флатпака.

Polugnom ★★★★★
()
Последнее исправление: Polugnom (всего исправлений: 1)
Ответ на: комментарий от fornlr

А насколько старое надо?

@intelfx

Вот, попробовал Inkscape, самый старый который во flathub есть. Февраль 2019 года.

Все ставится, подтягивает гномовый рантайм 3.30, поддержка которого была дропнута во флатхабе в январе 2020. Он ставится, все работает.

Более старый? Ну тогда совсем флатхаб маленький был, GTK2 кривое и все дела, смысла большого пробовать я не вижу.

James_Holden ★★★
()
Ответ на: комментарий от Legioner

Всё остальное считаю избыточным, мои проблемы это не решает точно, поэтому избегаю по мере возможности.

Так это надо у тебя спросить. Что такого плохого, что ты этого избегаешь.

James_Holden ★★★
()
Ответ на: комментарий от fornlr

Что же в .deb принципиально плохого?

Скрипты выполняемые с root правами.

Починил. Императивщине не место в пакетных менеджерах.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от ls-h

Предложенный вами реестр, разбитый на несколько файлов + с комментариями, не отличается от конфигурационных файлов.

Минус реестра это один большой файл.

Текст удобно редактировать в vi, nano, блокнот, sed, python+configparser + в самом файле могут быть комментарии - документация.

Если вам нужен контроль вводимых значений пишите утилиту gui для ввода контроля нужных значений, python+configparser вам в руки, но у меня раздражение вызывало, ползание по менюшкам настроек Microsoft IIS, c Аpache было в 10 раз быстрее и удобней.

У текстовых конфигов есть минусы: тяжело хранить бинарные данные: сырой текст, картинки, звуки и тп., плюс текстовые конфиги не должны быть большими, чтобы избежать этих минусов используйте файловую систему, базы данных.

s-warus ★★
()
Ответ на: комментарий от James_Holden

Я предпочитаю нативный софт. Написанный под мою конфигурацию. Моя конфигурация в настоящий момент это Fedora Gnome. Всякие Qt, Electron-ы, флатпаки, wine, java, это всё не нативное. По возможности я такого софта избегаю. Такой софт загружает в память лишние библиотеки, зачем мне это? У меня уже установлено достаточно библиотек для любых разумных задач. Про флатпаки я вообще слыхал, что они тянут копии системных библиотек других версий. Это очень странный подход. У меня место на диске не резиновое. Я хочу использовать софт, который использует те библиотеки, которые идут с системой, а не тянуть свои библиотеки.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 3)

Самый очевидный вариант - тарболы с исходниками.
С зондопроприетарщиной - на винду

TheAnonymous ★★★★★
()
Ответ на: комментарий от James_Holden

Да нет, много чего использую. Браузер, идея, виртуальные машины - в основном это всё.

Legioner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.