@MSGID: 2:463/68.300 64573801
@REPLY: 2:5000/14 6425f00c
@CHRS: CP1125 2
@TZUTC: 0300
@TID: hpt 1.2.4-release/bsd 30-05-03
 Hi,

 >>>> Eugene Muzychenko wrote:

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

Библиотеки отделяются по одной из трёх типовых причин:
 1. Есть несколько целевых бинарей с общим кодом, который надо
выносить в библиотеку.
 2. Авторы полагают достаточную вероятность их использования чем-то
ещё, а не основным приложением. Скорее всего - видят реальные примеры или
хотя бы запросы для них.
3. Удобство тестирования библиотеки отдельно от приложения.

 Это не всегда значит использование установленной в финальную версию
so`шки - часто используются промежуточные *.a. Hо если библиотеки ставятся,
их очень желательно ставить отдельно, в $prefix/lib[$platform_suffix].

 EM> Я правильно понимаю, что, если я сделаю приложение, код которого
 EM> разнесен по десяти библиотекам, и положу все это в один каталог, будут
 EM> свалка и бардак, а если положу основной файл в один каталог, а
 EM> библиотеки - в другой, то свалка и бардак будут ликвидированы?

Да.

 EM> Если
 EM> да, то хотелось бы узнать определение "свалки и бардака" с точки
 EM> зрения линукса. :)

 Когда соединяется вместе то, что не должно соединяться по каким-то
причинам, включая:

1. Платформенно-зависимые против платформенно-независимых компонентов.
Типа /usr/lib/x86_64-linux-gnu против /usr/share.

2. Исполняемые пути против неисполняемых.
/usr/bin, /usr/libexec... против /usr/libdata.

 3. То, что должно вызываться напрямую пользователем, против того, что
не должно вызываться. То же и для более двух уровней.
 Где-то, например, "moo buka" и "moo zuka" будут вызывать /usr/bin/moo
который после тщательной проверки и подготовки данных будет звать
/usr/libexec/moo/buka и /usr/libexec/moo/zuka соответственно.

 4. То что требует бэкапа для сохранения состояния текущей машины
(как /etc) против того, что не требует, потому что восстанавливается из
дистрибутива.

 5. Управляемое пакетным менеджером против установленного другими
средствами (snap, ручная компиляция для /opt или /site...)

Это с ходу, больше соображений в документе по FHS.

 Разумеется, идеала нет. Постоянно кто-то что-то нарушает, особенно в
корпоративной среде. В одном проекте свалка напрямую в /var без подкаталогов. В
другом конфиги в bin. Hо таких всё-таки малая часть от основного
использования.

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

 В этом тоже может быть смысл, если, например, разные FS будут
оптимизированы под мелкие или сверхкрупные файлы.
 Даже сейчас такое есть в плане количества инодов, но потеряло
актуальность с распространением FS с журналированием метаданных (ext4, UFS с
журналом), поэтому сейчас не актуализируется. Hо может, если опять станет важно.

 Про "не задумывается" неправда, постоянно думают. Вон например в FHS
много лет исключали полезность libexec-каталогов, сейчас восстановили хотя бы
частично.
Активно хотят свести вместе /bin и /usr/bin, аналогично большинство в /usr,
смысл разделения почти пропал. Вместо /var/run теперь /run. И прочая и прочая.
Мир плавно мутирует, рекомендации - вместе с ним.

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

 Логику grep легче и включить, особенно в монстра размера OO. Во
всём должна быть мера.

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

Ты как-то странно понимаешь unix way.
 Если бы он соблюдался, как ты описываешь, на 100%, то, например,
awk звал бы grep для каждого случая проверки шаблона в строке.

 Фактически, именно эта часть классического понятия "unix way" заточена
на то, что пока не становится слишком дорого - максимум кода пишется
последовательно на
1) шелле - всё что ещё можно им поддерживать;
2) скриптовалках (Perl/Python/etc.);
и только после этого включать компилируемые средства.

 Есть примеры продуктов - Git, Fidogate - которые ровно так и
делались. Пока нет причины использовать более низкоуровневые средства - остаются
на уровне повыше.

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

 Это ты описываешь винду начиная где-то так с момента массовой
рекламы использования PowerShell, который стал самопальным аналогом Perl+Python
как скриптующего клея.
 Да, с этого момента оно стало почти таким же - с поправкой на
десяток мелких деталей типа того, что для скриптов на PS постоянно всплывают
и исчезают через секунду консольные окна, заставляя пользователя
нервничать.
 Hо unix way старше лет на 25, за это время дети родились, выросли
и начали делать своё.

 VA>> Hапример, установка по-умолчанию Linux Mint или, скажем, Debian,
 VA>> компилятора не содержит. Что я делаю не так? ;)

 EM> Ты - не знаю. :) А вот люди, продвигающие идею собирать любой софт для
 EM> определенной системы непременно под самой этой системой, явно делают
 EM> что-то не так. :)

 Кросскомпиляции уже лет 60 в принципе. Для сборки под другую систему
есть контейнеры прочее.
Мы собираем, например, под Ubuntu/amd64 софт под RHEL/amd64, Yocto/aarch64,
Debian/arm32 и т.д.

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

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


-netch-

... И этот парашютист задолбал...

---
 * Origin: Dark side of coredump (2:463/68.300)
SEEN-BY: 50/109 250/25 301/1 341/66 450/1024 451/31
452/28 166 455/19 460/58
SEEN-BY: 463/68 877 1331 467/4 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/89 5058/104 5059/37
SEEN-BY: 5064/56 5083/1 6090/1
@PATH: 463/68 5020/1042 4441