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

Не читай больше этот сайт, это известная секта.

что имеется в виду?

Возможно, то, что очень много дырок было найдёно (и залатано) относящихся к библиотекам. Например, ты сделал mount -o noexec, а злоумышленник всё равно мог в старом libc вызывать программы через /lib/ld-linux.so.2 . Итд итп, много было дыр, в том числе с подменой окружения.

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

А если приедет апдейт foz с уязвимостями? Тогда уязвимыми станут сразу все программы, динамически с ней слинкованные.

Gobolinux

Там не статическая линковка. Там динамическая по принципу «всё своё ношу с собой».

В винде, помнится, некоторое время назад было былинное отверстие из-за того, что «.» находился в их аналоге ldpath.

Там динамическая по принципу «всё своё ношу с собой».

О БОЖЕ

Зачем?!

Но там, кстати, очень много здравых утверждений.

Кстати, как в plan9 предлагается делать, например, плагины и подмену библиотечных функций? Короткое гугление ничего не дало кроме как «это возможно и без разделяемых библиотек».

Здравых? Там шизоидный бред по всем пунктам.

что «.» находился в их аналоге ldpath.

А сейчас разве не так?

Зачем?!

Чтобы когда программа A работает с библиотекой X1.0, а B с библиотекой X1.1, их можно было безо всякого геморроя, присущего многим линуксам, поставить рядом.

Приведи свою аргументацию.

Назови причины, почему А не может работать с Х1.1?

нет исходников A?

И?

не-обратносовместимые изменения в X
альтернативы - либо ломать совместимость, либо таскать тонны ненужного легаси, которое еще и ресурсы на поддержку жрет

Если такие есть, Х1.1 будет называться Х2. Обе мирно и комфортно могут существовать в /usr/lib.

плагины и подмену библиотечных функций

Просто, учитывая, что большинство вещей в плане реализуется через IPC, а не через магические библиотеки. Даже к http идёт обращение через webfs.

Там шизоидный бред

Аргументы уровня ЛОРа.

большинство вещей в плане реализуется через IPC, а не через магические библиотеки

Так это должно быть ещё хуже по скорости, чем динамические библиотеки, и где-то так же по безопасности.

Украл мой комент. Плюсую вопрос про потерю перформанса.

то с динамической линковкой придется обновить только foz, а со статической — пересобрать все программы, использующие foz.

Ну зачем же мне все программы пересобирать (компилировать, что занимает львиную долю времени, и линковать), если их нужно только перелинковать. Поэтому-то гугл и работает над gold, быстрым линкером.

их нужно только перелинковать

А так же нужно хранить полные сырцы всего со всем выхлопом компилера.

Лично я голосую за упрощение механизма библиотек, а не за искоренение его.

Безопасность таки выше, а задержки на IPC далеко не всегда критичны.

Расскажи это разработчикам микроядра.

Например, ты сделал mount -o noexec, а злоумышленник всё равно мог в старом libc вызывать программы через /lib/ld-linux.so.2

по-мойму это был баг в ядре

их нужно только перелинковать

А так же нужно хранить полные сырцы всего со всем выхлопом компилера.

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

Лично я голосую за упрощение механизма библиотек, а не за искоренение его.

Я тоже считаю, что решение дебиана перейти с одной библиотеки на другую для всех пакетов, которое и им тяжело даётся, - это ограничение моего права выбора с удобством(!) собирать свои проекты с другой версией этой библиотеки. Достаёт ситуация:

$ ls -l /usr/lib/libscalapack-openmpi.*
-rw-r--r-- 1 root root 10718896 Dec 29  2011 /usr/lib/libscalapack-openmpi.a
lrwxrwxrwx 1 root root       25 Dec 29  2011 /usr/lib/libscalapack-openmpi.so -> libscalapack-openmpi.so.1
lrwxrwxrwx 1 root root       29 Dec 29  2011 /usr/lib/libscalapack-openmpi.so.1 -> libscalapack-openmpi.so.1.8.0
-rw-r--r-- 1 root root  7079640 Dec 29  2011 /usr/lib/libscalapack-openmpi.so.1.8.0
$ 

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

Тогда в примере с ошибочным поведением, можно было бы оформить баг-репорт, написать как правильную версию кода, так и с обходом. А решать, какую выполнять, каждый раз при старте программы, производя интроспекцию либы, которую подсунули в этот раз, в поисках тега баг «такой-то номер» исправлен. Вот только что-то нужно ещё добавить в процесс запуска: ведь мы не динамически подгружаем либу уже в рантайме (dlopen), а это выполняет ld-linux-....so за нас.

это был баг в ядре

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

Расскажи это разработчикам микроядра.

рассказал разработчикам QNX. Они говорят что ты дебил.

И только для некоторых пакетов, которые я сам пересобираю, придётся хранить объектники.

А разве не придётся хранить объектники для всех либ от которых зависят твои пакеты?

как довести до ума динамическую?

Да пролетают мысли как можно поменять. Я вот, например, хотел бы уйти от концепции размазывания пакетов по системе. Моё предложение: каждому пакету свою папку в которой была бы папка dependencies в которой есть симлинки на нужные версии пакетов. Это решает проблему наличия нескольких либ разных версий. Есть и другие варианты.

баг-фикс обновления либы прога перестала пахать

Это минус разрабам. Слышал, есть тулзы для проверки того что ABI не поменялся. По-моему, у qt такое видел.

Да, отлично. А объектники ты хранишь в гите наверное?

Зачем?!

В принципе, вся суть в одном посте: Сэндбокс для экспериментальных пакетов

Вообще это тема для толксов

со статической — пересобрать все программы, использующие foz.

В plan9 программ мало и они быстро пересобираются (нет ни boost, ни Qt, ни автошита), поэтому особой проблемы нет. С другой стороны, в динамически слинкованной системе добавляется «лишнее» звено — линкер — в котором могут быть уязвимости (в мохнатых годах они были и в линуксовом ld.so, сейчас — не в курсе, кто последним делал его аудит).

возможна ли статическая линковка всего

Нельзя собрать полностью статическую систему с современным glibc. Если без glibc, то можно попробовать, но определённый софт надо патчить, примерный объём патчей можно увидеть в репах того же alpinelinux.

И при этом забывают, что у них при передаче сообщений нет авторизации. Хотя нет, они сами в этом признаються. Там, где про Neutrino-specific security issues.

Это я к тому, что их перформанс существует только лишь за счёт того, что выкинули всё «ненужное». Это как хсервер, без ssh. Или telnet с plaintext паролями в пакетах. А как только это понадобится, начнутся костыли, тормозящие всё на свете.

Видну с двумя одновременно работающими антивирусами видел? Вот будет что-то похожее.

Плагины? Скриптами! :trollface:

при передаче сообщений нет авторизации

В Plan 9 — есть. Так что не надо приписывать ему QNX'опроблемы.

А с чего ты взял, что я что-то там приписываю plan9? Я про него вообще вспоминал?

Вопрос уже ставился ребром об асфальт: Динамическая линковка не нужна!

По сути, вот тебе ответ: каждый народ имеет право на свой ЛОР.

О БОЖЕ
Зачем?!

Просто коллега чего-то попутал. Никто там не отказывался от внешних зависимостей, там отказались только от FHS. Or so I'm told.

Статическая линковка (комментарий) — в каком-то смысле.

а задержки на IPC далеко не всегда критичны.

Расскажи это разработчикам микроядра.

Задержки IPC важны, иначе в микроядре не пытались бы всё сделать хоть чуть-чуть быстрее десятилетиями.

Конечно, спору нет. Если у тебя IPC работает через езернет, оверхед на фоне задержек сети просто нивелируется, но допустим у тебя тупая задача передачи данных, от плагина в програму чем быстрее, тем лучше. Что ты будешь делать? Правильно, оптимизировать тот самый IPC.

Туповатый анонимус ляпнул, и даже не разобрался, за счёт чего ipc qnx быстр, как сискол. Хотя бы почитал что-нибудь по теме. Тот же «A Critique of the GNU Hurd Multi-server Operating...» там всё расписано, что и как, хороший обзор, хотя и не про qnx. Да и торвалдс уже устал объяснять: ipc это либо медленно, либо не-(или тяжело) портируемо/несекурно/обрезано по самое нехочу.

Но всё же, если говорить о plan9. Ты сам сказал, что авторизация там есть, следовательно есть оверхед. Я не берусь утверждать, т.к. про план действительно знаю мало, но мне не вериться, что ipc plan9 не менее эфективен, чем вызов библиотечной ф-ии из библиотеки.

Может ли кто-нибудь объяснить, что имеется в виду?

ИМХО имеется ввиду то, что враг может подменить либу.

Олсо, возможна ли статическая линковка всего в современном линуксе

почему нет? В слаке думаю можно попробовать. Другое дело, что это идиотизм ИМХО. Типа «что-бы не ходить в грязных вонючих носках, надо ходить без носков». В принципе всё верно, но в целом немного непонятно...

Почему у меня получаются такие большие бинарники?

они долго грузятся и жрут память. И обидно, что одно и то же грузить надо. /bin/false состоит из двух(ДВУХ!) строчек, но таки разворачивается в Over9000, из которых большинство — хидеры к либам. Что, из-за 20К кода, который ничего не делает, грузить кучу НЁХ?

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

это как? Или ты про Swiss Cheese Authentication Modules?

Кстати, как в plan9 предлагается делать, например, плагины и подмену библиотечных функций? Короткое гугление ничего не дало кроме как «это возможно и без разделяемых библиотек».

будешь всё пересобирать, неужели непонятно?

Чтобы когда программа A работает с библиотекой X1.0, а B с библиотекой X1.1, их можно было безо всякого геморроя, присущего многим линуксам, поставить рядом.

и естественно это нужно делать по умолчанию! А то как же юзер будет второй IE ставить-то???

Назови причины, почему А не может работать с Х1.1?

потому-что ошибка в коде ДНК.

если их нужно только перелинковать

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

Безопасность таки выше

эффект неуловимого Джо в квадрате. Понимаю.

а задержки на IPC далеко не всегда критичны.

IPC

это такое заклятья оттуда?

А ещё дистрибутивам нужно было бы наконец-то поголовно перейти на обновление пакетов через бинарные дифы!

там профит минимален. Иной раз новый пакет весит меньше, чем дифф.

В итоге толку от версии 1.8.0!?

кто плакал, что хочет две версии сразу? Получи. Одна прога одно хочет, а другая другое. ПМ ставит обе.

Моё предложение: каждому пакету свою папку в которой была бы папка dependencies в которой есть симлинки на нужные версии пакетов. Это решает проблему наличия нескольких либ разных версий.

а мамку каждому?!

В plan9 программ мало и они быстро пересобираются (нет ни boost, ни Qt, ни автошита)

ну и нах оно нужно?

С другой стороны, в динамически слинкованной системе добавляется «лишнее» звено — линкер

ну да, а в статических нет?

Нельзя собрать полностью статическую систему с современным glibc.

что именно мешает, кроме упоротости?