Я тут подумал...

если авторы либы нумеруют API/ABI - либы станут параллельно. Если нет - все претензии не к методу линковки, а к автору либы

дело ведь не только в нумерации версий. дело в том, что у либы 1.0 и у либы 2.0 есть зависимости от других либ, у которых тоже есть зависимости, и т.п.

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

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

новые программы или стабильность?

почему я должен выбрать только одно из этого?

Если хотите и то и другое(и без хлеба) - собирайте статикой, на здоровье.

угу.. проблема в том, что я не хочу ничего собирать. это, кстати, не так просто сделать, когда возможность статической сборки разработчиками не предусмотрена (а это 99% случаев)

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

возможность статической сборки разработчиками не предусмотрена

А потому что ГЛИБ.

Да, понимаю. А ты считаешь, что функция C(из библиотеки lib), используемая программой A(слинкованной статически с lib), не будет использоваться программой B(слинкованной также статически с lib)? Если будет - нахрена нам удвоение объема кода в памяти? Есть только один выход, который почти устроит всех - memory pages deduplication. Тогда при статической линковке на ОДНУ и ту же версию либы, ф-ции будут присутствовать в одной копии в оперативе. Но это такой геморрой с технической точки зрения, что я даже представлять это себе не хочу...

почему я должен выбрать только одно из этого?

фууух. Ты ж разработчик? Что ж такие вопросы задаешь? Ты думаешь почему RedHat сидел на ядре 2.6.18, а сейчас на 2.6.32? От хорошей жизни? Потому что они сделали выбор - стабильность.

И почему многие сидят на генте/арче/whatever? Потому что - фичи. Вот я хоть и сижу на стабильной ветке в генте, всё равно понимаю, что это не тот «stable, rock solid». Но говно мамонта я люблю еще меньше, особенно когда там нет нужных мне по работе фич. Вот и получается противоречие, которое вижу я.

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

ну, так тогда жри что дают^W^W^W все претензии к мэйнтэйнерам твоего дистрибутива. Им проще делать так(я про динамическую линковку), как с точки зрения обеспечения поддержки пользователей, так и с точки зрения сопровождения самого дистрибутива.

Да, понимаю. А ты считаешь, что функция C(из библиотеки lib), используемая программой A(слинкованной статически с lib), не будет использоваться программой B(слинкованной также статически с lib)?

Будет.

Если будет - нахрена нам удвоение объема кода в памяти?

Это ещё вопрос что больше — оверхед на динамическую линковку или профит от неё.

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

С технической точки зрения динамическая линковка точно такой же геморрой, но пипл хавает.

фууух. Ты ж разработчик? Что ж такие вопросы задаешь? Ты думаешь почему RedHat сидел на ядре 2.6.18, а сейчас на 2.6.32? От хорошей жизни? Потому что они сделали выбор - стабильность.

я не сторонник мифа, что говно мамонта залог стабильности.

Это ещё вопрос что больше — оверхед на динамическую линковку или профит от неё.

Лично для меня - профит больше. Как там в бинарных дистрах - хз.

С технической точки зрения динамическая линковка точно такой же геморрой

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

Подытожу свою мысль насчет того, что хуже - динамическая или статическая линковка: «Обе хужи» (c) забыл кто

И да, про статическую линковку сейчас можно рассуждать лишь в том же ключе, что и про вейленд, то есть в сугубо теоретическом, потому что в современном линуксе всё прибито гвоздями к dlopen и прочим мерзостям.

Вот я хоть и сижу на стабильной ветке в генте, всё равно понимаю, что это не тот «stable, rock solid».

посиди на стабильном дебиане. быстро поймешь, что под словом «стабильность» они понимают неизменяемый номер версии.

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

а в CentOS 5 по-твоему компилятор какой версии? Всё также 4.1. То есть, хочешь писать на C++11 - изволь ставить его как хочешь. Никого не волнует... Ты же понимаешь, для разработчика такой головняк не очень хорошая идея. То ли дело гента - выбирай между мажорными версиями компилятора и ставь их хоть параллельно :-)

ну, так тогда жри что дают^W^W^W все претензии к мэйнтэйнерам твоего дистрибутива. Им проще делать так(я про динамическую линковку), как с точки зрения обеспечения поддержки пользователей, так и с точки зрения сопровождения самого дистрибутива.

так об этом и речь. выбора нет — приходится жрать что дают.

Лично для меня - профит больше. Как там в бинарных дистрах - хз.

Ну гентушникам как всегда — лишь бы поменьше компилировать.

В общем сейчас скачал потыкать в виртуалбоксе plan9 — экспериментальный юникс без шаред либ, посмотрим, сколько там что жрёт.

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

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

Будто фиксы не могут принести новые баги :3

поменьше компилировать

Угу, revdep-rebuild при обновлении либы(я держу одну версию, когда это можно), конечно же не перебирает полсистемы, доооо

у разработчиков софта есть разделение на стабильные релизы, всякие там беты, development-ветки

Да, это есть. Но не забываем про упоротых, у которых в стабильной ветке может быть писенящий душу леденец

объем кода фиксов как правило не сравним с объемом кода для вноса новой фичи. Проще говоря - шансов отстрелить ногу меньше, но он есть, да

а в CentOS 5 по-твоему компилятор какой версии? Всё также 4.1. То есть, хочешь писать на C++11 - изволь ставить его как хочешь.

зачем писать на чем-либо вообще в центоси?

Никого не волнует... Ты же понимаешь, для разработчика такой головняк не очень хорошая идея.

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

То ли дело гента - выбирай между мажорными версиями компилятора и ставь их хоть параллельно :-)

к счастью, таких юз-кейсов у меня тоже не бывает.

Да, это есть. Но не забываем про упоротых, у которых в стабильной ветке может быть писенящий душу леденец

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

Библиотеки Qt весят 12 мб. 5 запущенных приложений на Qt - лишние 60 метров оперативы.

Считать неумеем. При статической линковке используются не все библиотеки полностью а только нужные их кусочки, поэтому весить они будут 12/Х где Х целое число. Это при динамической линковке использовал одну функцию и несколько либ повисли в памяти, статика не грузит лишний мусор.

я не пишу на C++

а deadbeef чо, на яве штоле? o_O

Или ты имел ввиду ПО РАБОТЕ не пишешь на плюсах?

а deadbeef чо, на яве штоле? o_O

он на C.

Или ты имел ввиду ПО РАБОТЕ не пишешь на плюсах?

как раз на работе пишу на плюсах, но это не имеет отношения к линуху.

разумно, тут ты меня немного уел

А, ок. Почему-то думал что он на плюсах, хз почему. А qt-шная морда к нему тоже на чистом C? Там же вроде нужна магия^W^W нужны сигналы/слоты и прочие чудеса?

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

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

да все стрипают бинари после сборки. кроме дебаг-билдов.

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

но вот взять к примеру libsamplerate — в ней внутри огромный бинарный блоб с предрасчитанными таблицами. несколько мегабайт размером. а код занимает 2%

Я тут подумал...

Не делай так больше.

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

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

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

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

2 мейнстримовых DE
И самое ужасное - сотни, тысячи, сотни тысяч дистрибутивов, среди которых только одна рабочая

очевидные фиксы

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

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

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

а какого ж рожна при release-билде strip бинаря может отрезать от него до половины объема? Что это? Магия?

А ты открой непострипанный исполняемый бинарь как текст в восьмибитной кодировке и посмотри в конец файла - до четверти объёма занимает какой-то левый текст который ты не писал. Практически «Война и мир» в придачу к гуёвине. Это только лишний текст, впридачу к нему идёт ещё и лишняя информация в двоичном формате, всё вместе удваивает размер бинарника.

и? Ты ж утверждал что если собирать без дебаг-информации, то и стрипать кагбе не надо?

А так и есть:

begin
writeln('Hello world!');
end.

fpc hello.pas

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

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

осталось убедить авторов делать такие сборки.

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

с равной степенью вероятности может быть пониженное потребление.

Подай пример :-)

уже давно подаю:

http://deadbeef.sourceforge.net/download.html

http://deadbeef.sourceforge.net/portable.html

А, сорри :-) я просто другим плеером пользуюсь. Все бы так :-)

с равной степенью вероятности может быть пониженное потребление.

Если каждое чудо будет тащить в себе копию qt, откуда понижение?

Если каждое чудо будет тащить в себе копию qt, откуда понижение?

можно использовать GTK - тогда не надо ничего тащить, обратная совместимость гарантирована.

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

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

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

Это не выход. Это костыль. Потому что когда таких программ одна или две - это нормально. А когда их будет 100500 - это адъ. Особенно если учесть тот факт, что далеко не все разработчики будут делать нормальные статические билды, с включенными по-минимум функциями и правильно пострипанными бинарями.

А, и да. Если авторы будут делать такие сборки - на здоровье. Сущность поддерживаемого набора ПО всегда определяли мэйнтэйнеры дистрибутивов. Энтерпрайз-дистры скорее всего скажут таким сборка GTFO, community-based протяжно вздохнут и возьмутся за поддержку пользователей...

не надо ничего тащить

а сам GTK, пускай и не весь, который будет туда влинкован - не?