>>> в лине разделяемые библиотеки кажись как раз для борьбы с "ожирением"
>>> системы придумали?
>> Для борьбы с «ожирением» производителей проприетарного ПО.
>> Просто возьмите калькулятор и посчитайте в цифрах, сколько там памяти экономится за
>> счёт разделения именно секциями кода и неизменяемых данных. Если справитесь, попробуйте
>> сравнить со статическим связыванием. Для затравки: приложение уровня HelloWorld это порядка
>> 8-30 Кб _без_ зависимостей, что сверху - это от умелых ручек.
> тратилось много, при недостатке оперативной памяти, поскольку грузилось все в неё(может
> это был предыдущий виток желаний производителей?). из-за этого постоянный свопинг и
> прочие удовольствия.

Это было "лишь бы не как в Венде", где исполняемые образы не читались целиком в память, а отображались, и неизменяемые страницы просто отбрасывались. Либо смотрели в будущее, понятно же было, что объёмы ОЗУ растут и подход Linux в итоге окажется чуть быстрее в работе.

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

Да просто сравните размер исполняемого файла chromium или firefox с объёмом памяти, что они потребляют при запуске. Мегабайт и гигабайт. Не играет роли, считать .so или нет. А вот если 64-х разрядные указатели в графах сократить до 32-х - может сэкономиться процентов эдак 20.