На сайте «Компьютерры» опубликовано интервью с разработчиком Deepsolver

В отличие от, где пакет просто напросто ругнется и предложит тебе сосать лапу если не подключен к сети.

По меньшей мере в тех дистрибутивах GNU/Linux, которые используют RPM, существует возможность установить пакет, игнорируя зависимости. Как он после этого будет работать — другой вопрос

То есть, пользователю пофиг, качнуть одну библиотеку, или качнуть кучу ПО, часть из которого ещё и неизвестно, когда обновится ?

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

Программы ставить надо не откуда попало, а из репозитария. ;-) Ага, привет проприетарному ПО.

Почему проприетарному, что СПО для вин/маков уже отменили?

А если в твоём отдельном раздельчике для винды отсутствует софт? Точно так же качать будешь.

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

Открой для себя в апте ключик только-скачать. И можешь таскаться с этими файликами так же.

Ты опять уходишь от ответа о размере всех этих файликов в репозитарии.

А зачем нужна библиотека ради библиотеки?

1) никто не предлагает искусственно плодить библиотеки и вообще основная идея состоит как раз в том, чтобы искуственно не делать ничего - ни объединять, ни делить. Что есть в проекте, то и есть.

2) Лицензионные проблемы тоже никто не отменял. Если библиотека совместима с разделяемой линковкой, то из этого никак не вытекает, что возможна и статическая.

3) библиотеки обычно чужие. В том же freeswitch вложено десятка полтора либ. И все они цеплябтся как разделяемые.

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

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

пнх, короче

Понятно, у тебя есть позитивный опыт работы. У меня его нет. Поэтому и спросил, чем он примечателен.

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

P.S.

Кстати, не подумай, что я генту хвалю. Там тоже полно своих причуд.

Из linux систем мне запомнились только 4-ре. Красная шапочка, дебиан во второй половине 90-х. Убунта и генту в 10-х. Красная шапка в те годы была очень шустрой на 2-x процессорном pentium pro, дебиан заработал даже на моем карманном psion 5mx. С принтером на аккумуляторах и инфракрасным портом, мобильным инетом неплохой мобильный офис получался. А после долгого перерыва попробовал начать с легкого - с убунты, но быстро перешел на калькулейт, так как все-таки убунта мне показалась медлительной. Ну а затем и вовсе сделал свой генту-стейдж для простоты. Теперь полная переустановка системы на моем нетбуке, включая обычную перезагрузку занимает 3 минуты. Тот же альт, убунта и другие бинарные дистрибутивы устанавливаются так же долго как и седьмой офтопик. Калькулейт установился в 2010-м минут за 7. И это меня зацепило.

А что, афигительно удобно возить с собой в поездку/на дачу/командировку пачечку с DVD

Пачку - это если тебе для работы нужен Debian.

Если нужен Debian, то достаточно флешки с /var/cache/apt .

Почему проприетарному, что СПО для вин/маков уже отменили?

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

Пункт три - не проблема, если я не ошибаюсь, а вот два... Это, пожалуй, да. Но, всё же, это не сильно частый случай наверное, можно и через LD_LIBRARY_PATH выкручиваться. Мне кажется, не сильно и плохой вариант.

Пункт три - не проблема

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

Но, всё же, это не сильно частый случай наверное, можно и через LD_LIBRARY_PATH выкручиваться. Мне кажется, не сильно и плохой вариант.

Нормальный вариант.

<troll>они переизобретают portage, очевидно же :-)</troll>

Вымещаешь здесь свои комплексы?

Говори по теме, тебе ответят. Твои попёрдывания из за угла никому не интересны.

они переизобретают, очевидно же :-)

FIXED

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

Ну пересоберёт, выпустит обновление, в чём проблема то?

Ну пересоберёт, выпустит обновление, в чём проблема то?

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

В том же freeswitch вложено десятка полтора либ. И все они цеплябтся как разделяемые.

Неправда. Не все. freeswitch плохой пример, как мне кажется.

Неправда. Не все. freeswitch плохой пример, как мне кажется.

вопрос вовсе не в том, что плохой пример, а что хороший.

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

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

Ну дык Ubuntu рекомендуют вообще раз в полгода переустанавливать: http://www.google.ru/#hl=ru&gs_nf=1&cp=35&gs_id=a&xhr=t&q...

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

То есть win дистрибутивы уже содержат все необходимые зависимости, а lin нет, но они тянутся отдельно так? Ок, тогда виндовые дистрибутивы должны быть более объёмные очевидно. Смотрим:

Windows 32 bits Blender 2.63a Installer (27 MB)
Linux x86-32 Blender 2.63a (42 MB)

Apache_OpenOffice_incubating_3.4.0_Win_x86_install_ru.exe 2012-05-06 128.9 MB
Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_ru.tar.gz 2012-05-02 145.6 MB

В чём тут профит для пользователя?

В чём тут профит для пользователя?

OpenOffice - специфичный продукт. У него, как раз, «всё своё ношк с собой» сильно развито. И пришёл он не из Linux вовсе. И не был всегда открытым. Наследие прошлого.

Ты опять уходишь от ответа о размере всех этих файликов в репозитарии.

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

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

Да.

Даже статистика есть у тебя?

Не читатель? На сайте «Компьютерры» опубликовано интервью с разработчиком Deepsolver (комментарий)

OpenOffice - специфичный продукт. У него, как раз, «всё своё ношк с собой» сильно развито.

Хорошо, все с собой, но ведь и в win дистрибутивах так же? Но почему они весят меньше?

Или даже еще веселей. Новые версии для win (Audacity например, да много чего) выходят сразу, а обновлений для Ubuntu фиг вам, только к следующему релизу Ubuntu. Или качать новые исходники + туеву кучу новых зависимостей и компилять с непонятным результатом.

Не читатель? На сайте «Компьютерры» опубликовано интервью с разработчиком Deepsolver

чО за бред? Слово статистика тебе знакомо? Берёшь список программ и сравниваешь размеры в винде и _репозитарии_. А потом вывод делаешь. На тебе для примера: ls blender-2.62* -rw-r--r-- 1 ftp ftp 15075940 Apr 06 18:23 blender-2.62-alt1.i586.rpm ls libreoff* -rw-r--r-- 1 ftp ftp 86657350 Jul 05 13:28 libreoffice-3.5.5.3-alt1.i586.rpm ls blender* -rw-r--r-- 1 500 500 13841560 Jun 26 21:50 blender-2.63a-2.fc18.i686.rpm ls blender* -rw-r--r-- 1 500 500 26241167 May 11 08:45 blender-2.63a-1.mga2.i586.rpm

Хорошо, все с собой, но ведь и в win дистрибутивах так же? Но почему они весят меньше?

Я же сказал, он не из Unix появился. Тяжёлое наследие от необходимости поддерживать версии Windows и OS/2. *nix был много позже. Опять же, как бы MS не хаяли, но компилятор у них получше оптимизирует код, чем GCC, вынужненный буть кроссплатформенным. Чем OOo собирают под Win ?

Ты хоть со своей Linux системой знаком?

Ну попробуй закачай из своего репозитария ОТДЕЛЬНО файлик .rpm программы, потом выдерни сетевой шнурок и попробуй его установить. Результат можешь не озвучивать.

Потом вставь шнурок обратно, и попробуй заново, увидишь сколько гумна этот файлик за собой потянет. Результат тебя приятно удивит. А потянет он явно больше того-же отдельного дистрибутива для винды. Это и называется зависимости.

Даже статистика есть у тебя?

Не читатель? На сайте «Компьютерры» опубликовано интервью с разработчиком Deepsolver...

Кстати, а откуда эти дровишки ? Что за Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_ru.tar.gz ?
Это не с сайта ли зазработчика универсальный deb подо всё дебианоподобное ? А то, как-то, в репах ALT Linux оно значительно худее. Хоть и «всё своё ношу с собой». Видать, уже несовсем всё.

UPD: точно. apt-cache depends libreoffice показывает список зависимостей аж за экран. Значит, работают.

Ну попробуй закачай из своего репозитария ОТДЕЛЬНО файлик .rpm программы, потом выдерни
сетевой шнурок и попробуй его установить. Результат можешь не озвучивать.

Это тут к чему ? Оно на то и разделяемые библиотеки, чтобы общие пакеты с собой не паковать.

Тяжёлое наследие от необходимости поддерживать версии Windows и OS/2. *nix был много позже.

Это кроссплатформенное п.о. Про поддерживать тяжелое наследие, с таким же успехом можно сказать и про линукс, не суть. Но блендер допустим в юниксах изначально был, тоже win дистриб меньше.

Чем OOo собирают под Win?

Без понятия если честно.

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

Меньше, чем Блендер где ? Размер в ALT уже тоже показали. А, на самом деле, в пакете ещё присутствует сжатие, оно может быть везде разное, в бинарниках может быть, а может и не быть отладочная информация.

Это тут к чему ?

Если эти конкретные файлы, нужны этой конкретной программе, их всё равно требуется выкачать и установить. Чего толку считать объём голого файлика .rpm программы? как товарищ выше калькулирует.

если эти конкретные файлы, нужны этой конкретной программе,

Нет. Совсем нет. Это Java, это glibc, это libX11 и прочие libX и т.п. Тут выкладывать не буду, список большой. Но нет ничего чисто офисного.

То есть win дистрибутивы уже содержат все необходимые зависимости, а lin нет, но они тянутся отдельно так?

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

Меньше, чем Блендер где ?

Ну ё моё, Иван Иваныч..

Windows 32 bits Blender 2.63a Installer (27 MB)
Linux x86-32 Blender 2.63a (42 MB)

На сайте «Компьютерры» опубликовано интервью с разработчиком Deepsolver (комментарий)

Нет. Совсем нет. Это Java, это glibc, это libX11 и прочие libX и т.п. Тут выкладывать не буду, список большой. Но нет ничего чисто офисного.

То есть эти зависимости не требуемые, их можно не скачивать, и программа без них установится?

15078569 Jul 9 22:35 blender_2.62-alt0.M60P.2_i586.rpm Это «чуть-чуть» меньше.

То есть эти зависимости не требуемые, их можно не скачивать, и программа без них установится?

Нет, программа без них не установится. Но без libX* не будет работать много что ещё, а без glibc не будет работать ничего вообще. Без Java у меня не заработает нортеловский Java Device Manager.

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

Эмоциями

Иди уже.

Нет, программа без них не установится.

Ну дык и смысл тогда сравнивать размер голого .rpm пакета программы с самодостаточным win дистрибутивом. В сумме объём закачанных данных будет больше. В некоторых случаях это неудобно, по причине дорогого/медленного интернета.

Ты хоть со своей Linux системой знаком?

Ну попробуй закачай из своего репозитария ОТДЕЛЬНО файлик .rpm программы, потом выдерни сетевой шнурок и попробуй его установить. Результат можешь не озвучивать.

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

apt-get install blender -s Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: libpython3 python3 python3-base python3-modules-tkinter The following NEW packages will be installed: blender libpython3 python3 python3-base python3-modules-tkinter 0 upgraded, 5 newly installed, 0 removed and 730 not upgraded.

lдобавь ещё 5 мегов. всё равно меньше будет.

То есть эти зависимости не требуемые, их можно не скачивать, и программа без них установится?

винда сёморочка. из официальных требований 16 гиг на винте, или 20 гигов для 64-разрядной. после установки можно только поиграть в сапёра. но зато его скачивать не надо. какие плюсы, вах-вах.

винда сёморочка. из официальных требований 16 гиг на винте

11 gb системная папка на 60 gb разделе, хватает.

11 gb системная папка на 60 gb разделе, хватает.

это какой-то позор(c)

http://windows.microsoft.com/ru-ru/windows7/products/system-requirements

16 гигабайт (ГБ) (для 32-разрядной системы) или 20 ГБ (для 64-разрядной системы) пространства на жестком диске;

Кстати, а откуда эти дровишки ? Что за Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_ru.tar.gz ?

http://sourceforge.net/projects/openofficeorg.mirror/files/localized/ru/3.4.0/

ты туда ещё приплюсуй двд с дебианом. без него же работать не будет.

Ну дык и смысл тогда сравнивать размер голого .rpm пакета программы с самодостаточным
win дистрибутивом. В сумме объём закачанных данных будет больше. В некоторых
случаях это неудобно, по причине дорогого/медленного интернета.

Чего больше !? Зачем мне отдельная Java для каждого пакета ? На кой чёрт мне своя libX11 для каждого X-ового приложения ? У меня _уже_ есть Java. LibreOffice не тянет свою и не занимает лишнее место.

Кстати, а откуда эти дровишки ? Что за Apache_OpenOffice_incubating_3.4.0_Linux_x86_install-deb_ru.tar.gz ?

http://sourceforge.net/projects/openofficeorg.mirror/files/localized/ru/3.4.0/

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

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

У ООorg есть сборки как с java так и без, на выбор.

Если эту уникальную версию библиотеки прилинковать статически

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

И всё-таки они почти все, за исключением самых системных и тяжёлых, линкуются в бинарник статически, это от ЯП зависит. Даже иксы запихиваются в сторонние либы и потом их можно использовать в системе без иксов для сборки ПО.

в нынешних условиях объем или слишком велик или слишком мал. Экономия пары мегабайт никого не согреет.

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

и будет меньше сложностей с менеджерами памяти, внутри бинарника он один.

Это вообще надуманно.

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