Идея новой подсистемы разделяемых библиотек. Критикуем.

ничего нового не предложили ,
symbol versioning активно используется в библиотеках, в частности в GLIBC

ps: хэши не нужны
ставится symbol@GLIBC_VERSION

например fallocate@GLIBC_2.11

>при загрузке программы грузится в память не весь код, а только реализации функций, которых нет в памяти.

Ога, а в самой библиотеке входящие в неё ф-и не использовать, дабы избежать наложения, так? )

>Значит, подгружаться будет, к примеру, 10% от размера статического бинарника.

И много по-вашему в типичной системе статически слинкованых бинарников?

Линковать всё статически? Ну уж нет. Так гигабайтов не напосёшься.

> ничего нового не предложили ,

symbol versioning активно используется в библиотеках, в частности в GLIBC

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

Я говорю совершенно о другом.

О xintrea!

xintrea всех умнее и милее, на свете этом всем, он героически обязан засверлится дрелью срочно. ну ты понял.

> Ога, а в самой библиотеке входящие в неё ф-и не использовать, дабы избежать наложения, так? )

Всмысле? Библиотека сама по себе в память не грузится. На то она и библиотека. Библиотека подгружается, если программа ее требует. О каком наложении идет речь?

>Вопрос: есть ли какая-то принципиальная ошибка в описанной системе?

да:

Запускаемая программа должна содержать все библиотеки, которые ей нужны.

> Линковать всё статически? Ну уж нет. Так гигабайтов не напосёшься.

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

Для особо упоротых возможен вариант подгрузки системной библиотеки, почему нет. Только если появится описываемая подсистема, то системными либами пользоваться будут одни красноглазы и составители дистров, обеспечиващие наличие библиотек «на первое время».

>ставится symbol@GLIBC_VERSION

А если версия GLIBC_VERSION изменилась, ну скажем вышла новая версия GLIBC 2.12 а сама функция осталась неизменной, т.е. точно такой же как в GLIBC 2.11 ?

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

А потом и все приложения собрать в 1 большой бинарник, как это в busybox или leechcraft

> да:

Запускаемая программа должна содержать все библиотеки, которые ей нужны.

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

> И много по-вашему в типичной системе статически слинкованых бинарников?

rod linux - 100%

> Значит, подгружаться будет, к примеру, 10% от размера статического бинарника.

> Идея новой подсистемы разделяемых библиотек.

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

а вообще, мне кажется, что аватар ТС'а хорошо иллюстрирует его предложение )))

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

Если бы это было так - я бы не пользовался линупсом вообще.

Если я вижу инсталлятор одной проги под венду и линупс, то вендовое будет метров на 200 больше, так как в комплекте пойдет все необходимое. И я точно знаю, что через 2-3 клика будут запущены инсталляторы библиотек, если это необходимо. Зато в линупсе я с вероятностью в 80% нарвусь на какие-то зависимости и предложение обновить половину системы на достаточно старом дистре (я вот сейчас сижу на дистре 2005 года, без апдейтов). Ради 1-2 приложений я не собираюсь ломать свою теплую и ламповую систему, мне проще слить статический бинарник и радоваться жизни. Аналогично и в венде - скачал софт - оно гарантированно работает. Игры с системными апдейтами для тех, кому слишком скучно в жизни, меня не прикалывает, что что-то мне потом надо будет восстанавливать, где-то слетят настройки или произойдут «улучшения», которых я не планировал. Да, апдейты я выключаю сразу при установке системы, не важно что за дистр.

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

Правильно. Если разработчик у себя на компьютере слинковался с libabcd x.y.0, то ни в коем случае нельзя линковать программу с libabcd x.y.5, она же исправила ошибки, а разработчик этого не ожидал. При обновлении libabcd с x.y.z на x.y.z+1 нужно срочно пнуть разработчика, чтобы выпустил новую версию. Если с библиотекой слинковано сотня программ, нужно дождаться, пока все разработчик их обновят.

Дальше продолжать?

Тут две проблемы.

Во-первых, либо это приведет к тому, что ненужный код из бинарников будут strip'ать (либо на сервере, где лежит программа, либо на целевой машине), чтобы сэкономить трафик и место на диске, либо, как тут и говорят, «гигабайт не хватит». при текущем состоянии дел с бинарной совместимостью в линукс каждая такая программа будет иметь половину дистрибутива при себе.

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

Как правило лепятся разные воркароунды, которые при исправлении ошибок перестают работать -> разработчика все равно пинать. НО ЗАЧЕМ?

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

Всё как раз наоборот - динамическая линковка более молодая чем статическая.

Вот четыре основных способа линковки:

dynamic - независимые от программ библиотеки. Программа линкуется с библиотекой и нужные функции вызываются из неё (call to c, например). В целом (что бы вы ни думали) это самый гибкий подход.

static - все нужные функции линкуются в единый бинарник. За исключением рантайма.

image based - всё сохраняется в один образ, в том числе рантайм.

tree shaking - тот же полный образ из которого убраны все недостижимые функции.

Вы вроде говорите о четвёртом способе. Ну так берите Ada, Haskell, коммерческие CL - там именно такие умные статические линковщики есть. В свободном SBCL (CL) существует feature request по поводу поддержки первого способа (вообще-то всегда были fasls, но это не соотносится с c-world) - а вы предлагаете всему посвящённому миру вернутся в средневековье?)

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

А вот за это держите афоризм: «Talk is cheap. Show me the code.». Убеждённость ещё не пропала?)

З.Ы. «более другой» - так нельзя сказать :)

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

Расскажи это сану с его инсталляторами Java SDK, разработчикам nVidia, Opera, WmVare, Skype, Qt Creator и прочим. Можешь еще сановскми разрабам StarOffice рассказать что они все делали неправильно, и что из него OpenOffice получился чисто случайно.

Кстати, ЕМНИП, какие-от из ранних ОС именно так и работали. Но чего-то в них кому-то не понравилось.

> Как правило лепятся разные воркароунды

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

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

>А вот за это держите афоризм: «Talk is cheap. Show me the code.».

К сожалению, именно этот афоризм привел ко большинству проблем в линухе.

Можно поступить иначе - не писать быдлокод.

> Правильно. Если разработчик у себя на компьютере слинковался с libabcd x.y.0, то ни в коем случае нельзя линковать программу с libabcd x.y.5, они же исправили ошибки...

и добавили новые.

...а разработчик этого не ожидал.

во-во.

При обновлении libabcd с x.y.z на x.y.z+1 нужно срочно пнуть разработчика, чтобы выпустил новую версию.

Зачем??? Если программа работает и выполняет свою функцию с libabcd с x.y.z, зачем, скажите мне, срочно обновляться на x.y.z+1? Только ненадо рассказывать про безопасность - в макоси вон как-то живут, и в ус не дуют.

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

А пока они лежат в трекере сидеть и плевать в потолок?

К сожалению, именно этот афоризм привел ко большинству проблем в линухе.

Ладно. Но TC далеко не уедет без кода :) Не спорю - иногда одной идеи достаточно, если она хороша. Но идеи я не вижу (пока).

И еще вот что. Все это дело сводится к одному вопросу: а каких библиотек ожидать в любом дистрибутиве, чтобы их не прикладывать. Все ведь до ядра включительно не приложишь.

А если этот вопрос будет, наконец, решен в рамках LSB, то, я думаю, их предложений уже хватит для решения большинства проблем.

> Расскажи это сану с его инсталляторами Java SDK

Засунь весь этот хлам разработчикам туда, откуда они его родили. Если они хотят использовать статические бинари, угадай, сколько там пересечений с остальной системой, сколько процентов пользы от этого будет в идеальном случае и сколько — в случае конкретно моего десктопа или десктопа васи пупкина. Алсо:

/usr/lib/opera/opera: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped

/usr/lib/openoffice/program/soffice.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

/usr/bin/qtcreator: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

ldd этих файлов показать или на слово поверишь?

> А пока они лежат в трекере сидеть и плевать в потолок?

бить, сказал же

>Как правило лепятся разные воркароунды

Воркараунды? Как правило? Хорошенькие у вас правила.

НО ЗАЧЕМ?

Внезапно, авторы libabcd выпустили важное исправление или починили дыру.

> Внезапно, авторы libabcd выпустили важное исправление или починили дыру.

ВНЕЗАПНО там все работало, пусть и с дыркой, но работало. А если автор приложения забил х**, то с новой либой все сообщество будет тихо посасывать.

>ВНЕЗАПНО там все работало, пусть и с дыркой, но работало.

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

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

fixed

>> Нужен более другой механизм линковки, а в данный момент линух застрял на методологии тридцатилетней давности.

Всё как раз наоборот - динамическая линковка более молодая чем статическая.

И появилась тридцать лет назад.

tree shaking - тот же полный образ из которого убраны все недостижимые функции. Вы вроде говорите о четвёртом способе. Ну так берите Ada, Haskell, коммерческие CL - там именно такие умные статические линковщики есть. В свободном SBCL (CL) существует feature request по поводу поддержки первого способа (вообще-то всегда были fasls, но это не соотносится с c-world) - а вы предлагаете всему посвящённому миру вернутся в средневековье?

Я говорю о будущем. Понятно, что в сишных языках не в лоб реализуется tree shaking, как это возмножно в функцинальных. Но прогресс же не стоит не месте, вон LLVM какие возможности по сравнению с gcc дает. При желании будет и в c-world tree shaking.

А вот за это держите афоризм: «Talk is cheap. Show me the code.». Убеждённость ещё не пропала?

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

Такое не нужно.

> А если этот вопрос будет, наконец, решен в рамках LSB, то, я думаю, их предложений уже хватит для решения большинства проблем.

Я думаю, это было бы идеально.

>ВНЕЗАПНО там все работало, пусть и с дыркой, но работало. А если автор приложения забил х**, то с новой либой все сообщество будет тихо посасывать.

Дык, зачем посасывать? Поставить старую версию в отдельное место, настроить LD_LIBRARY_PATH для этой программы и запускать. Если программа нужная, ее в конце концов к новой либе приспособят.

Ъ делают workaround'ы методом написания своего велосипеда, а не использования неправильно работающей функции.

>Если я вижу инсталлятор одной проги под венду и линупс,

наверни ка дерьма. припиетарные блобы и под вендой и под линаксом распространяются со своими библиотеками. а свободному софту т.н. «инсталлеры» не нужны.

> Дело сдвинется с мертвой точки только тогда, когда хотя бы горстка вменяемых людей осознает, что это необходимо.

вменяемых

это необходимо

Взаимоисключающие параграфы.

классная аватарка, прямо по теме {:

фанатик? Вот честно, мне в этом плане венда больше нравится.

ldd этих файлов показать или на слово поверишь?

Давай, cравним.

ldd Opera vs Konqueror:

/opt/opera_10_60/lib/opera$ ldd opera
        linux-gate.so.1 =>  (0xb7f04000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7dfa000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7dec000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0xb7de3000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0xb7dcc000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0xb7db9000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7d44000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7d2b000)
        librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7d22000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7d1e000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7d08000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7c1a000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7bf4000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7be7000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7a8c000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7a61000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7a57000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7a55000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7a3d000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7a3a000)
        /lib/ld-linux.so.2 (0xb7f05000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7a14000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7a0e000)

/usr/bin$ ldd konqueror
        linux-gate.so.1 =>  (0xb7f02000)
        libkdeinit_konqueror.so => /usr/lib/libkdeinit_konqueror.so (0xb7df5000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d07000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7ce0000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7cd3000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7b78000)
        libkonq.so.4 => /usr/lib/libkonq.so.4 (0xb7aee000)
        libkutils.so.1 => /usr/lib/libkutils.so.1 (0xb7a86000)
        libkdeui.so.4 => /usr/lib/libkdeui.so.4 (0xb777c000)
        libkio.so.4 => /usr/lib/libkio.so.4 (0xb7403000)
        libkparts.so.2 => /usr/lib/libkparts.so.2 (0xb73bd000)
        libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0xb6c8a000)
        libDCOP.so.4 => /usr/lib/libDCOP.so.4 (0xb6c53000)
        libkdecore.so.4 => /usr/lib/libkdecore.so.4 (0xb69ef000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb6900000)
        /lib/ld-linux.so.2 (0xb7f03000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb68ea000)
        libkdefx.so.4 => /usr/lib/libkdefx.so.4 (0xb68c0000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb68b2000)
        libkdesu.so.4 => /usr/lib/libkdesu.so.4 (0xb689d000)
        libkwalletclient.so.1 => /usr/lib/libkwalletclient.so.1 (0xb688d000)
        libfam.so.0 => /usr/lib/libfam.so.0 (0xb6883000)
        libacl.so.1 => /lib/libacl.so.1 (0xb687c000)
        libattr.so.1 => /lib/libattr.so.1 (0xb6877000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb684c000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb6836000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0xb67e5000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb67c6000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb67a2000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb679a000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6791000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb678b000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6781000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb677e000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0xb676b000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb66f6000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0xb66ee000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0xb66d7000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb66d2000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb66b9000)
        libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb66a3000)
        libidn.so.11 => /usr/lib/libidn.so.11 (0xb6672000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb6670000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6657000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6654000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb662e000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6629000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6623000)

Заодно вспомним, что в Opera есть Mail и Torrent клиенты, а в 10.60 еще и виджеты...

Кстати, либы, используемые в Opera, можно рекомендовать для LSB, за исключением разве что libfontconfig и libfreetype.

> Дык, зачем посасывать? Поставить старую версию в отдельное место, настроить LD_LIBRARY_PATH...

А пользователи винды и мака просто запускают setup...

ну так и вали на виндоз 7 максимальную. скачивай устанавливай вручную груду программ (каждую со своей кривой велосипедной обновлялкой), касперского и набор троянов. и даже не думай заносить путь к бинарнику в PATH, windows way это каждый раз набирать в консоли C:\Program Files\Asshole Soft Some Program v.10\bin\SomeProgram.EXE

> windows way

набирать в консоли

I LOL'd