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

cat-v.org - это диагноз.

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

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

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

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

нужна.

Кто-то соскучился по winsxs.

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

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

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

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

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

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

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

Они и так в другом мире :) У них там своя атмосфера

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

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

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

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

+1048576

Нет. И в указанном в начале треде хорошо описано почему.

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

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

И в указанном в начале треде

В котором?

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

про убунту

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

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

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

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

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

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

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

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

он стал свободным только к 2000-м, когда он был уже не нужен

А стал бы он свободным, если бы был нужен?

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

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

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

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

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

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

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

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

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

про убунту

Который там про убунту?

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

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

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

/thread

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

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

Roman Shaposhnikov, 2007

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

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

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

Не пойми кто

<btdn>...

<aiju>...

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

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

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

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

заменить ... alsa на pulseaudio

охлол

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Irony Man to the rescue!