@MSGID: 1:104/117 642724b9
@REPLY: 2:5000/14 6425f00c
@CHRS: CP866 2
@TZUTC: -0600
@TID: hpt/lnx 1.9 2022-07-03
Привет, Eugene!

30 Mar 23 21:53, ты писал(а) мне:

Последний ответ. Я устал. :) Без обид.

 VA>> Потому что в линуксе так принято. Для этого разработан стандарт.
 EM> Hа основании чего разработан стандарт, требующий отделять собственные
 EM> библиотеки приложения, которые гарантированно не потребуются никому
 EM> другому? Ты точно понимаешь этот стандарт правильно?

Я точно понимаю этот стандарт правильно.

 VA>> Никто не мешает тебе устанавливать либы туда, куда захочется. Но
 VA>> тогда будет свалка и бардак.
 EM> Я правильно понимаю, что, если я сделаю приложение, код которого
 EM> разнесен по десяти библиотекам, и положу все это в один каталог, будут
 EM> свалка и бардак, а если положу основной файл в один каталог, а
 EM> библиотеки - в другой, то свалка и бардак будут ликвидированы? Если
 EM> да, то хотелось бы узнать определение "свалки и бардака" с точки
 EM> зрения линукса. :)

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

Вот пример, как это можно упорядочить:
https://packages.debian.org/buster/amd64/libreoffice-writer/filelist

 VA>> https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#purpose
 EM> Слово "libraries" встречается там только в контексте "shared
 EM> libraries" и "libraries for programming and packages". К какой
 EM> категории из этих двух относятся собственные библиотеки приложения?

Shared library - это бинарный файл .so. Пофиг, шарится он реально или нет.

 VA>> это работает десятилетия и всех устраивает.
 EM> Если ввести отдельные каталоги для текстов и изображений, это тоже
 EM> будет работать десятилетия. А на вопросы можно будет привычно отвечать
 EM> "так заповедано предками", и говорить, что "всех устраивает". :)
 EM> Может, большинство просто никогда не задумывалось?

 Очень сомневаюсь, что разработчики Unix/Linux настолько тупые и
никогда не задумывались 30+ лет. Просто эта логика не такая, как в других
операционных системах. Я лично не знаю, чем они руководстовались, но прежде, чем
критиковать, стоит попробовать следовать стандарту. Даже если он непонятен сразу и
кажется странным, это чаще всего не так.

 VA>> Тулы для прогижания болванок. Там основная программа - это только
 VA>> запускалка других программ, которые подготавливают образ и
 VA>> собственно прожигают образ на болванку. Отличнынй пример
 VA>> unix-way.
 EM> Согласен. А текстовый процессор? Я с OO, конечно, почти не имел дела,
 EM> но что-то не припомню, чтоб он для поиска в документе выгружал его в
 EM> текстовый файл, прогонял по нему стандартный grep, после чего разбирал
 EM> его вывод.

Это маловероятно, но такое тоже может быть.

 VA>> Можно запускать консольные приложения вручную. Можно использовать
 VA>> их в скриптах, можно использовать GUI.
 EM> Можно-то оно можно. Hо как много ты знаешь сколько-нибудь сложных и
 EM> ходовых продуктов (текстовые и графические редакторы, средства
 EM> разработки ПО, отладчики, средства разработки электронных схем и ИС,
 EM> средства научных расчетов и моделирования и т.п.), которые следуют
 EM> unix way, запуская для выполнения каждой функции полностью
 EM> изолированную программу, работающую в отдельном процессе, и общаясь с
 EM> нею средствами межпроцессного общения?

 Ты сам привел пример. Отладчик. Даже в Visual Studio отладчик - это
отдельный процесс. Почему его не встроили в саму студию. Пусть даже в виде
отдельной dll? ;)

 VA>> если тула пришла из мира windows, то конечно же они плевать
 VA>> хотели на unix-way.
 EM> Подозреваю, что это никак не зависит от мира. Если есть запрос на
 EM> доступ к функциям ПО в пакетном режиме, то в винде это делается, как я
 EM> уже описал - вынесением кода в DLL, к которой могут обращаться как
 EM> гуевые, так и консольные процессы. Полная инкапсуляция кода в
 EM> консольном процессе встречается лишь тогда, когда приложение было
 EM> изначально запланировано сугубо консольным, а примитивный гуй был
 EM> позже слеплен на коленке чисто для ламеров, не осиливших консоль. И
 EM> то, подозреваю, разработчики потом кляли себя за то, что изначально не
 EM> оформили функциональность в виде движка, сразу положив в DLL, которая
 EM> полноценно используется и консольным, и гуевым вариантами приложения.

В линуксе это тончо так же выносится в shared library (so). Никакой разницы.

 EM>>> сколько часто используемых библиотек требует сборки непременно
 EM>>> под конкретную версию?
 VA>> Не распарсил вопрос. Переформулируй.
 EM> Сколько типовых, используемых разным софтом линуксовых библиотек
 EM> требует непременной сборки под конкретную версию дистрибутива? Отчего
 EM> нельзя сделать одну-две-три для привязки к особенностям дистрибутива,
 EM> чтоб остальные были универсальными, общаясь с системой через эти
 EM> выделенные?

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

 VA>> А если в приложении используется несколько разных версий одной и
 VA>> той же библиотеки
 EM> В одном приложении, понятное дело, такое использоваться не должно.
 EM> Хотя, с нынешней модой на зависимость от десятков библиотек, легко
 EM> нарваться на то, что какие-то из них будут хотеть разных версий одних
 EM> и тех же основных библиотек.

 Если разные зависимости будут использовать разные версии одной
библиотеки - очень-очень высока вероятность, что оно взорвется. Особенно, если
это dll/so.

 VA>> Например, установка по-умолчанию Linux Mint или, скажем, Debian,
 VA>> компилятора не содержит. Что я делаю не так? ;)
 EM> Ты - не знаю. :) А вот люди, продвигающие идею собирать любой софт для
 EM> определенной системы непременно под самой этой системой, явно делают
 EM> что-то не так. :)

 Я тебе больше скажу, таких людей - подавляющее большинство. Особенно
те, кто продвигают header-only библиотеки. Под винду вообще каждая либа
чаще всего собирается отдельно под каждый проект, даже не под систему.

Best regards,
Vitaliy Aksyonov.

... Акелла промахнулся, впрочем как всегда...
--- GoldED+/LNX 1.1.5-b20230221
 * Origin: Aurora, Colorado (1:104/117)
SEEN-BY: 50/109 104/117 250/25 301/1 341/66
450/1024 451/31 452/28 166 455/19
SEEN-BY: 460/58 463/68 467/888 4500/1 5000/111
5001/100 5005/49 5010/352
SEEN-BY: 5015/42 46 5020/113 545 620 715 830 846
848 1042 4441 12000 5022/128
SEEN-BY: 5030/49 115 1081 5036/26 5049/1 5053/51
5054/8 89 5058/104 5059/37
SEEN-BY: 5064/56 5083/1 6090/1
@PATH: 104/117 5020/1042 4441