Статическая линковка

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

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

plan9? Вопрос не ко мне. IDE из него, конечно, ещё интереснее, чем из линукса с «на этот раз, всё — файл» и нативным sam.

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

В 100% статичном дистрибутиве линкер нафиг не нужен в рантайме. Можно представить себе статически собранный дистрибутив без компилятора/линкера, обновляющийся через rsync или что-нибудь подобное. По крайней мере в пределах одной фирмы.

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

its design decision to use dlopen for certain “separated” library features (NSS, locales, IDN, …), which makes it nearly impossible to use glibc for static linking in non-trivial programs. То есть проще собрать систему на другом libc.

Что мешает не думать обо всём этом и просто пользоваться динамической линковкой (если речь идёт не о мини-системе для околоembedded-целей) — вопрос не ко мне.

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

Кстати, есть мнение, что реализовывать всё через IPC — рудимент, оставшийся со времён, когда динамической линковки в *никсах не было. Понятное дело, что кое-где демона （неважно, что за IPC у него торчит наружу — сокет, 9p или что ещё) не заменить динамической библиотекой, но некоторые люди слишком увлекаются распиливанием софта.

plan9? Вопрос не ко мне. IDE из него, конечно, ещё интереснее, чем из линукса с «на этот раз, всё — файл»

какие профиты даёт этот лозунг?

нативным sam.

wtf?

В 100% статичном дистрибутиве линкер нафиг не нужен в рантайме.

угу. А rpm не нужен в слаке. Но есть. И как ты думаешь — зачем? Причём в слаке-то всё работает, а вот в plan9 — сам знаешь.

Можно представить себе статически собранный дистрибутив без компилятора/линкера, обновляющийся через rsync или что-нибудь подобное. По крайней мере в пределах одной фирмы.

можно. Ну в масштабах локалхоста точнее. Представить и ужаснуться.

its design decision to use dlopen for certain ”separated” library features (NSS, locales, IDN, …), which makes it nearly impossible to use glibc for static linking in non-trivial programs. Unfortunately, for certain tools we will ship glibc for pragmatic reasons.

ну а что они хотели-то? Ясное дело, что тут 5и грамм упорина не хватит. Тут полкило надо.

Но я так и не понял — зачем?

Вопросы производительности и безопасности — спорные. Большие файлы долго грузятся и занимают много места. В современных процессорах они и работают медленно, ибо в современных процессорах есть большие и быстрые кеши. Там можно хранить часто используемые либы, которые используют несколько одновременно работающих программ. Однако, если каждая прога тянет с собой свои либы, то все сразу они в кеш никак не войдут. Это приведёт к тому, что время переключения между программами возрастёт многократно. Ну а многоядерные процессоры в принципе не смогут работать иначе, кроме как с одним ядром (общая память ведь одна, и ядра могут только разделять общий кеш и пользоваться персональным)

Что касается безопасности, то тут тоже всё плохо. IRL через никому ненужный забор просто перелезть. Просто потому, что никто за ним не следит. И если там есть дыра, это никого не волнует, и охранник об этом даже и не знает(да и знать не желает, ибо всё равно брать нечего).

это как?

posix capabilities http://fedoraproject.org/wiki/Features/RemoveSETUID

У подхода с IPC есть свои преимущества: независимость от языка программирования, лёгкость эмуляции (дай каждому приложению свой /dev/audio, и микшируй/перенаправляй звук без создания велосипедного api. В частности, rio делает нечто подобное, но с мышью и текстовым вводом/выводом). Для добавления промежуточного слоя в линуксах нужны костыли вроде loop, tun/tap, ALSA plugins, fuse и многие другие, в Plan 9 сервис подменяет файл в пространстве имён, и всё просто работает. Причём, так как пространство имён у каждого процесса своё, подобное действие локализовано, а не действует на всю систему.
Подобной гибкости сильно не хватает в юниксах.

есть большие и быстрые кеши. Там можно хранить часто используемые либы

Кхм, тесты в студию. Вот у меня данные по fx-8120 у которого кэш инструкций общий для ядер. Так вот, в десятке на вскидку выбранных тестах всё упирается в данные, а не в L1i кэш.

С другой сотроны, статически собранные программы сами по себе работают быстрее.

Это приведёт к тому, что время переключения между программами возрастёт многократно.

Это сказки.

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

plan9 — сам знаешь

замечания от мимокрокодил - в plan9 есть возможность запускать линуксовые программы через эмулятор.

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

И тем не менее в ядре будет реализация D-Bus.

А сам читал? Ну читай: In some cases this might not be possible.

А то, что его ставить не нужно где не поподя — я и без тебя в курсе. Лет 10 назад народ увлекался этим битом, но дело давнее, да и вариантов не было. SUID bit — самый быстрый способ. Сейчас конечно во первых компы побыстрее стали, а во вторых есть уже в ядре и SELinux и APPArmor, если что, можно наворачивать любые самые запутанные схемы. А раньше тебе хочешь-не хочешь, но надо было поставить SUID на cdrecord, ибо иначе болванок больше запаровалось. И внутрь ядра тоже кагбэ пихать запись болванок не комильфо.

Кхм, тесты в студию.

я не настолько упорот, что-бы статически пересобирать. Мне это и так очевидно.

Вот у меня данные по fx-8120 у которого кэш инструкций общий для ядер. Так вот, в десятке на вскидку выбранных тестах всё упирается в данные, а не в L1i кэш.

ну это сейчас, пока места в кеше у тебя полно. А вот если в кеше будет лежать Over9000 _одинаковых_ либ, то я посмеюсь на твой третий пень. Просто ни у кого в голову не приходит так делать, только у здешних диванных теоретиков. Вот пусть они и тестируют. Только пусть учтут, что «OS» это не только команда cat.

С другой сотроны, статически собранные программы сами по себе работают быстрее.

в гордом одиночестве быстрее — не спорю. Потому-как _одна_ программа конечно влезет в кеш, и со всеми своими либами. А вот Over9000 влезет?

Профит либ в том, что они РАЗДЕЛЯЕМЫЕ, и потому есть смысл мучиться с их динамической линковкой. И потому _одна_ программа запускается медленнее(если с so). Ибо проще одним куском взять с диска бинарник уже подключённый в 2Мб, чем с того же диска брать 40К, а потом эти 2Мб линковать. Проблема только в том, что у меня кеш всего 2Мб+2Мб, а процессов 137. И трёхгигового кеша у меня нет. А у тебя?

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

Опровергни, если такой умный.

И да, ладно я такой дурачок, но почему умные люди с баблом в это не вкладываются? А вкладываются в «финского студента с кривой наколенной архитектурой»?

замечания от мимокрокодил - в plan9 есть возможность запускать линуксовые программы через эмулятор.

я слышал об этом. Однако зачем, если есть Linux?

В принципе, все, что не прибито гвоздями к особенностям какой-либо системы, можно собрать и для plan9.

угу. «в принципе» на хлеб не намажешь.

Подобной гибкости сильно не хватает в юниксах.

Для чего её нехватает? Удобство кодинга? Всё давно написано. Если оно даёт измеряемые конкретными цифрами плюсы — можно их увидеть?

И да, ладно я такой дурачок, но почему умные люди с баблом в это не вкладываются? А вкладываются в «финского студента с кривой наколенной архитектурой»?

Батю пошло колбасить уже по всем тредам. Его эпичная неспособность читать скоро станет мемом.

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

Пиндосам же только, или наконец-то расширили? А к какому «сословию» вы себя относите, батенька?

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

А сейчас уже нет, что ли? Это ж тогда куча всего поломаться должна.

man libpng

Опровергни, если такой умный.

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

А сам читал?

Да, внимательнее чем ты. Смотри ссылку на багтрекер, увидишь как один за другим убирали setuid с пакетов. Это тебе было для затравки, остальное ищи сам. Хотя, зачем тебе, можно же сделать вид что «я всё равно умный, вооон там написано что иногда без этого никак, значит можно смело утверждать что suid до сих пор всем нужен».

SUID bit — самый быстрый способ. Сейчас конечно во первых компы побыстрее стали

При чём тут скорость?

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

Это не системы раздачи прав, это системы их урезания. Совсем другая вещь.

Олсо, возможна ли статическая линковка всего в современном линуксе с количеством костылей, меньшим, чем в Gobolinux? (inb4 зачем? низачем. просто интересно.)

Во-первых, нужно будет заменить чем-то gnu libc. gnu libc не умеет в статическую линковку.

Во-вторых, всякие gtk её тоже не особо любят.

А в остальном проблем нет.

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

Для этого в plan9 делался 9p.

А есть бенчмарки этого всего дела? Это бы влило гораздо больше определённости чем тупые диванные разговоры «это будет тормозить! Нет, не будет!»

нужно будет заменить чем-то gnu libc

dietlibc

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

На этапе запуска программы - нет.

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

упоротость glibc мешает

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

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

А, понял. Я думал про '.' как про каталог, в котором лежит бинарник.

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

когда набор программ компактный, относительно редко меняющийся, оттестированный и еще произведенный/проверенный одним вендором - тогда всё ОК, и для вылавливания уязвимостей так лучше. а вот когда чуть больше зоопарка, тогда начинается то, что сегодня имеем.

«Баг» который известен всем на протяжении многих лет является фиче.

А есть бенчмарки этого всего дела? Это бы влило гораздо больше определённости чем тупые диванные разговоры «это будет тормозить! Нет, не будет!»

Я о таких не слышал. Было бы интересно. Другое дело, что 9p он тупой и простой. Особо тормозить не должен.

Динамическая линковка - это костыль в операционной системе. К тому же ещё и потенциальная дыра в безопасности.

Другое дело, что 9p он тупой и простой. Особо тормозить не должен.

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

нужно будет заменить чем-то gnu libc

musl же есть.

Динамическая линковка - это костыль в операционной системе

костыль по какому критерию?

типикал виндомышление

Кстати, есть мнение, что реализовывать всё через IPC — рудимент, оставшийся со времён, когда динамической линковки в *никсах не было

plan9 --- сетевая операционная система. Как ты предлагаешь заменить ipc динамической библиотекой, если процессы выполняются на разных хостах?

Как ты предлагаешь заменить ipc динамической библиотекой, если процессы выполняются на разных хостах?

Ну, например, от запуска ftp-клиента на другом хосте не так много смысла по сравнению с встраиванием библиотеки. И достаточно очевидно, что call быстрее, чем общение с другим процессом по 9p (пусть во многих случаях это и некритично).

Ну, например, от запуска ftp-клиента на другом хосте не так много смысла по сравнению с встраиванием библиотеки.

Нераспарсил.

пусть во многих случаях это и некритично

Именно.

Смотри ссылку на багтрекер, увидишь как один за другим убирали setuid с пакетов. Это тебе было для затравки, остальное ищи сам.

ты бы и поискал. Это совсем не только в твоей красношапке было, это в любом дистре так было. В slackware тоже.

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

а моё утверждение неверное? Тебе не нужны sudo/su? Ты работаешь под рутом?

При чём тут скорость?

а ты голову подключи. Оно, знаешь-ли, полезно. Обдумай например нужность костыля sudo, который раздаёт права в соответствии с твоими сложными правилами, посылает куда-то почту, пишет какие-то логи и т.д., если права можно выдать и так, проще и _быстрее_. И очень удобно для всех: админу достаточно сделать chmod +s, а юзеру вообще думать не нужно: просто тыкаешь, и всё работает.

Это не системы раздачи прав, это системы их урезания. Совсем другая вещь.

facepalm

какую принципиальную разницу ты нашёл в «раздаче» и «урезании»? Это, блжад, одно и то же. Просто эти системы работают вместе с обычной моделью, и потому общее их действие — конъюнкция частей. Недостаток unix-like прав в том, что для неё ВСЕ(один) админы локалхоста имею одинаковые права, потому права в твоей федорке как в маздае — админу можно всё. Раньше плодили юзеров, каждого со своими правами, но ведь выж даже юзера создать не в силах, потому-то и пришлось делать для админов локалхоста app armor, защищающий их от них же самих.

Во-первых, нужно будет заменить чем-то gnu libc. gnu libc не умеет в статическую линковку.

Во-вторых, всякие gtk её тоже не особо любят.

А в остальном проблем нет.

это такой сарказм? Или я чего-то не понял, и множество «остальное» не пусто?

А есть бенчмарки этого всего дела? Это бы влило гораздо больше определённости чем тупые диванные разговоры

в том-то и прикол: бенчмарки ЧЕГО? Было-бы что тестить, я-бы сам не балоболил, а давно-бы посмотрел своими глазами. И уже с пруфами тут распинался. Кричал-бы: «вы все ***, а я Д`Артаньян, и у же поставил, и УМВР!!!111»

Но тестить нечего.

На этапе запуска программы - нет.

угу. В теории, если ВСЕ программы его не хотят.

упоротость glibc мешает

ну называй это «упоротостью». Хотя как по мне это напоминает школу, в которую _каждый_ школьник ходит в сопровождении тридцати _своих_ учителей. Не, я понимаю, какие-то плюсы тут безусловно есть, но школьный в класс тупо не влезет 30 школьников и 900 учителей. Где я ошибаюсь?

«Баг» который известен всем на протяжении многих лет является фиче.

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

Вот тебе более близкая аналогия IRL: в офисе есть маленький ящик с секретными документами, в который не должен лазать Вася. Ещё есть пила, которой можно распилить ящик. Ещё есть ключ от ящика. Ты покупаешь сейф, что ты в него положишь? Вот я тоже-бы положил ящик, но ты кладёшь туда ключ от ящика. И возмущаешься, что пила не влезает. И зря возмущаешься, потому-как даже если пила влезет, Вася принесёт свою пилу. Или топор, или просто этот ящик об стену расколет. А знаешь где твоя ошибка? А ошибка в том, что ты оставил Васю без присмотра один на один с уязвимым ящиком. Единственное, что ты сделал — сделал недоступным ключ. На самом деле, недоступность ключа это ещё не всё. К ящику надо ещё охранника поставить, который следит, что-бы ящик никто не открывал, кроме как ключом, который защищён. Или сам ящик защищать. Но не так, как это сделал ты.

Динамическая линковка - это костыль в операционной системе. К тому же ещё и потенциальная дыра в безопасности.

если у меня 100+ процессов, то без этого костыля не обойтись.

костыль по какому критерию?

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

пришлось делать для админов локалхоста app armor, защищающий их от них же самих.

Эмм. apparmor позволяет ограничить каждый процесс ровно тем, что ему нужно для штатной работы, и тем самым ограничить ущерб от возможных уязвимостей (а ошибки есть в каждой крупной программе). Это вполне неплохой инструмент. Реализовать точно то же самое системой chroot'ов и пользователей невозможно, кстати.

как в маздае — админу можно всё.

В маздае админу можно далеко не всё.

Основную часть памяти занимают данные, более того, есть такие штуки в ядре, как MADV_MERGEABLE но куда диванному теоретику это знать. Да ещё нищебродство вызывает зуд, небось.

Я тебе написал ответ, но кода увидел вот это:

пришлось делать для админов локалхоста app armor

мне стало смешно и я всё удалил потому что тебя не интересует сама дискуссия, тебе нравится работать на публику. Хорошо получается, когда-нить в топ lorquotes попадёшь.

Не надо разрушать ему хрустальные замки, ведь он большой «тралль » и всё такое.

Почему тогда эту «фичу» исправили?

если процессы выполняются на разных хостах?

Я бы ещё добавил, что хосты могут иметь различные архитектуры.