LINUX.ORG.RU
ФорумTalks

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

 , , , ,


0

2

Вы только вдумайтесь! Linux занимает на десктопах 1.5%. По моим подсчетам, это где-то 50-70 миллионов десктопов. Но при этом, мы имеем 5 мейнстримовых DE, еще штуки три не шибко популярных, и с десяток WM. Каждое DE пилит свой файломенеджер, браузер на вебките, и черт знает что еще. И самое ужасное - сотни, тысячи, сотни тысяч дистрибутивов. Каждый популярный дистрибутив пилит свой пакетный менеджер, и еще кучу велосипедов (я этой темой не шибко интересуюсь). Что мы имеем в итоге? Весь линукс, одна сплошная раздробленность, где любой конфликт между разработчиками решается тем, что кто-нибудь уходит, и начинает пилить свой велосипед. Я считаю, бешеные человекоресурсы разбазариваются, на создание очередного клона аудиоплеера (тонкий укол в сторону разрабов Audacious), файломенеджера или недайбох DE. Конечно, не мне решать, чем заниматься этим людям, и что нужно, а что нет. НО! Open Souce сообщество, задумайся, прежде чем создать очередной клон клона. А то более ли менее профессиональный софт (да хотя бы не вылетающий редактор видео), и как следствие вендекапец, мы заполучим еще очень нескоро, в нашем уютном линуксике....

Ответ на: комментарий от Pinkbyte

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Будет.

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

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

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

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

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

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

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

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

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

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

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

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

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

Pinkbyte ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

он на C.

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

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

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

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

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

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

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

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

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

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

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

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

waker ★★★★★
()

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

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

z00ke
()
Ответ на: комментарий от Pinkbyte

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

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

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

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

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

waker ★★★★★
()

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

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

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

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

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

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

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

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

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

А так и есть:

begin
writeln('Hello world!');
end.
fpc hello.pas
GCC так не умеет но это проблемы его пользователей и разработчиков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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