LINUX.ORG.RU
ФорумTalks

Динамическая линковка не нужна!

 ,


0

6

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

И вот, уже пошли мнения о том, что «проще все линковать статически» и «может, вообще тогда отказаться от .so»?

Что это, очередные закидоны ЛОРовцев или реальная идея? За советами мы решили обратиться к самым старперным специалистам в глобальной компьютерной сети «Интернет». Вот что они пишут (выдержки/сокращения):

Rob Pike (один из разработчиков Unix, Plan 9, нескольких языков программирования и не только), 2008

В первом докладе Sun Microsystems о том, как они реализовали в своей ОС динамические библиотеки, сообщалось, что система получилась больше и медленее. Места на диске экономилось совсем мало. Тесты проводились на Xlib, и заключение было таково: преимуществ нет, одни недостатки.

Да, все современные ОС их поддерживают, но это не значит, что это хорошая мысль. В Plan 9 мы пытались избавиться хотя бы от некоторых необоснованных вещей, которые «все делают».


Geoff Collyer, 2002

Нет, у нас [в Plan 9] не вся библиотека C в каждой программе. В каждой программе содержится только копия каждой вызываемой (прямо или косвенно) функции.

Разделение (sharing) кода производится на уровне секций кода (text segments), как в Unix V6 или V7. При форке процесса потомок будет пользоваться тем же кодом, что и родитель, за счет соответствующего маппинга страниц памяти. Если несколько раз запустить одну и ту же программу с помощью exec, все эти процессы разделят код.

С учетом такого разделения и низких цен на RAM (...) я не вижу нужды в разделяемых библиотеках. Вспомним, что в Unix их реализовали, в первую очередь, из-за громоздких и страшных библиотек X11, а большинству наших пользователей сего дара Божьего удалось избежать.

Отметим, что безо всяких разделяемых библиотек утилиты в Plan 9 при аналогичных возможностях обычно меньше по размеру, чем программы из FreeBSD.


Не пойми кто

<btdn> Я никак, ну вот хоть убей, никак не могу понять, зачем люди используют динамическое связывание.
<aiju> btdn: Потому же, почему верят в Бога.


Roman Shaposhnikov, 2007

Что общего между разделяемыми библиотеками и коммунизмом? Очень просто: и то, и другое в теории выглядит прекрасно, а в реальности провалилось с треском. (...) Поищите файлы .so в любом коммерческом или бесплатном, но большом пакете. Не удивляйтесь, если там даже специальные версии glibc попадутся.



Ссылочки (источники и не только):
http://harmful.cat-v.org/software/dynamic-linking/
http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols
https://blogs.oracle.com/rvs/entry/what_does_dynamic_linking_and
http://port70.net/~nsz/32_dynlink.html

Где план9 и где линукс?! В теории у этого плана всё замечательно, а на практике пшик, очередной «научный» прожект, как и миникс с микроядром.

daemonpnz ★★★★★ ()

С учетом … низких цен на RAM (...) я не вижу нужды в разделяемых библиотеках.

Я за бан этих товарищей из мира компьютеров.

Deleted ()

Я могу сказать одно, gcc и в текущей реализации pthread_* ругается на статическую линковку по-жесткому, а именно требование динамеческой загрузки libpthread.so. Все это значит, что грядут перемены! И будет счастье (надеюсь), ибо такая политика не тру, даже с соблюдением всех тонкостей gpl + system libs specific.

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

Они по следам удачного монолитного ядра пытаются сделать монолитную ОСь?

// Казалось бы, при чём здесь емакс..

schizoid ★★★ ()

linux + blackbox + fvwm + emacs, и никакой plan9 не надо.

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

geekless ★★ ()

Леннарт был бы доволен.

AX ★★★★★ ()

Джон Кармак тоже недолюбливает динамическую линковку:

“I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.”

hydrogen ()

Разделение (sharing) кода производится на уровне секций кода (text segments), как в Unix V6 или V7. При форке процесса потомок будет пользоваться тем же кодом, что и родитель, за счет соответствующего маппинга страниц памяти. Если несколько раз запустить одну и ту же программу с помощью exec, все эти процессы разделят код.

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

andreyu ★★★★★ ()

Похоже, что им принесли.

Quasar ★★★★★ ()

Разделяемые библиотеки были необходимы, чтобы 640К всем хватало. Сейчас в них смысла гораздо меньше.

Miguel ★★★★★ ()

Plan 9 имеет полноценный файлоподобный IPC с неймспейсами, юниксы — не имеют.
Так что так просто избавиться от динамического связывания не выйдет.
> Разделяемые библиотеки были необходимы, чтобы 640К всем хватало. Сейчас в них смысла гораздо меньше.
Внезапно, статически слинкованные приложения могут быть даже меньше.

И да, кстати: от этого вашего динамического связывания fork/exec становится ОЧЕ медленным.

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

Монолитной ОС является как раз линукс со всякими systemd, в плане же небольшие приложения общаются друг с другом через 9P.
И файловые системы реализуются приложениями вне ядра.

quantum-troll ★★★★★ ()

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

Смотрим, на Windows и Linux (системы, активно использующие динамические библиотеки, их используют миллионы пользователей, есть вменяемый GUI и огромная база приложений), смотрим на Plan9 (система, которую используют 3,5 гика, с интерфейсом хуже Win95 и 1,5 приложениями). Да, действительно, использование статических библиотек очень помогает придти ОС к успеху.

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

Все проблемы от ленивых девелоперов, которые не хотят обновлять вовремя приложения под новые ABI библиотек.

KivApple ★★★★★ ()

Те, кто говорит, что динамическая линковка не нужна, могут вспомнить эпическую историю примерно 10-летней давности, когда было обнаружено двойное освобождение памяти в zlib.

Если все программы в системе слинкованы с одной so, то при исправлении бага достаточно только обновить только её. Если куча программ слинкована статически с lib, то привет, обновляем эту кучу.

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

Лол, но чем дальше движется линукс, тем чаще мы вспоминаем Plan 9.

Да, действительно, использование статических библиотек очень помогает придти ОС к успеху.

Главная проблема плана была в том, что он стал свободным только к 2000-м, когда он был уже не нужен. Успех линукса связан с тем, что это первая свободная ОС: у BSD были патентные трудности — что ж, теперь BSD считается R.I.P.

quantum-troll ★★★★★ ()
Ответ на: комментарий от i-rinat

Судя по истории юникса, не стал бы. В любом случае, закрытая исследовательская ОС была просто обречены на провал, так как для коммерческих целей были юниксы, а сообщество СПО было занято созданием свободного клона юникса, и ему было не до экзотических закрытых ОС.
Bell Labs, похоже, так и не заметили, что 70-е давно прошли.

quantum-troll ★★★★★ ()
Ответ на: комментарий от akk

Если все программы в системе слинкованы с одной so, то при исправлении бага достаточно только обновить только её. Если куча программ слинкована статически с lib, то привет, обновляем эту кучу.

Это, казалось бы, несомненный плюс. Но обновление можно организовать через двоичный diff (zsync или похожее), так что всё можно организовать быстро.

А вот, контрпример, когда улучшенная версия либы кладёт некоторые приложения. Недавно такой шум поднялся: Дреппер против Торвальдса. Уже вспомнился? Да, ускоренный memcpy.

И в дистрибутивах типа стабильного Дебиана было бы легче обновлять отдельные пакеты, не боясь ненароком угрохать что-то из-за того, что от либы зависит 1001 пакет.

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

Но обновление можно организовать через двоичный diff (zsync или похожее), так что всё можно организовать быстро.

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

quantum-troll ★★★★★ ()
Ответ на: комментарий от andreyu

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

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

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

Если все программы в системе слинкованы с одной so, то при исправлении бага достаточно только обновить только её. Если куча программ слинкована статически с lib, то привет, обновляем эту кучу.

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

Miguel ★★★★★ ()

Динамические библиотеки позволяют заменить init на systemd или alsa на pulseaudio и не переустанавливать всю систему.

/thread

quiet_readonly ★★★★ ()
Ответ на: комментарий от quantum-troll

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

Так с проприетарщиной и так всё плохо:

Roman Shaposhnikov, 2007

Поищите файлы .so в любом коммерческом или бесплатном, но большом пакете.

Например, Altera Quartus с qt4, tcl, и ещё чем-то.

Или какие приложения, например, имеются ввиду?

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

Не пойми кто

<btdn>...

<aiju>...

aiju - это Julius Schmidt. Хотя сравнение, на мой взгляд, неудачное.

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

Я имею в виду, что ты не можешь просто перелинковать проприетарную программу, так как лицензия может запрещать изменение, а код считать собственную контрольную сумму.
Так что zlib в опере не пропатчешь.

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

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

Я, скорее, не понял, в чём может быть проблема с двоичными патчами? Не право ли это производителя решать, как он эти патчи оформляет?

gag ★★★★★ ()

Ну динамическая линковка лишает возможности проведения LTO, плюс template библиотеки и так не линкуются.

Но все же нужно их не выпиливать, а грамотно модернизировать. Я бы при компиляции в бинарь клал все его зависимости, но разделял их на сегменты. Для каждого сегмента (кода или данных) - считаем хеш, если такой сегмент уже загружен в ОС - эту часть файла мапить не нужно. Сложность только в том, как правильно разбивать на сегменты.

snizovtsev ★★★★ ()

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

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

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

Уже есть Zero Install. Почему тебя это раньше не волновало?

ZenitharChampion ★★★★★ ()

В случае дырки в openssl мне не придётся пол системы выкачивать заново.

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

PS про память и скорость всё это сказки. Пока не увижу две системы собранные целиком статически и динамически я не поверю что одно лучше другого. Синтетические бенчмарки и «вот сосед Вася что-то там намерял» это фуфловые аргументы.

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

все основные дистры до сих пор выкачивают пакеты целиком, даже если поменялась только иконка

Федора выкачивает диффы. Иногда.

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

Что такое, при линковке shared object невозможно LTO?

А как возможно выполнить LTO между приложением и линкуемой библиотекой, если она линкуется динамически? Если только не требовать, чтобы библиотека никогда не менялась (тогда зачем линковать динамически)?

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

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

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

Пока не увижу две системы собранные целиком статически и динамически я не поверю что одно лучше другого.

Справедливости ради стоит сказать, что этот эксперимент крайне трудно провести. Поскольку если просто взять, например, ГНУтый Линукс и собрать все статически (что еще не факт, что получится), люди скажут: «Ну, это фигня: вот вы проведите все возможные оптимизации для того, разделение кода в памяти, бинарные патчи для быстрых обновлений и проч., тогда и поговорим». А если даже у кого-то хватит терпения сделать/форкнуть какую-либо ОС так, чтобы она оптимально работала и в статической, и в динамической сборке, люди скажут, что это две разных ОС и эксперимент нечестный.

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

у сиих специалистов это главный аргумент

Это весомый аргумент. Если окажется что после нововведения стало жить только хуже то ну нафиг такое.

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

инкрементирую, налейте чайку этому господину.

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

Что такое, при линковке shared object невозможно LTO?

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

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

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