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

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

>основном из-за apt... sinaptic... и

имхо urpmi поудобней и пофичастей будет.

> по инету шарить в поисках пакетов для Mandriva

Советую почитать доки по urpmi и про то как подключать официальные репозитории. База пакетов там не меньше чем в debian'е.

> А что, хакеры нынче тупые пошли, не могут подправить контрольные

> суммы, чтобы чайник ничего не заметил?

Я специально для таких как ты несколько раз повторил, что список контрольных сумм (база сумм) подписан PGP дистрибутора. Видимо малое количество раз повторил :-)

>> AFAIK LZMA хорош на т.н. solid-архивах (это когда набор файлов перед сжатием переупорядичавается по типу), так что на единичном файле (будь-то tar или cpio) ефект значительно снизится.

>Solid - это когда все файлы воспринимаются архиватором как единое целое. То есть *.tar.gz - тоже solid. Если для сортировки по типу и есть специальное название, я его не слышал ни разу. Сортировка по типу, действительно, полезна, но, имхо, если словарь достаточно большой - разницы не будет (другой вопрос, осилит ли машина такой размер словаря :) ). Имхо, проблема zip/gzip и bzip в том, что у них размер словаря фиксирован, и для современных нужд маловат.

Чушь !

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

Отсюда следует *.tar.gz - это не solid. Tar ведь не сортирует файлы по типу.

В режиме solid cортировка по типу очень полезна для сжатия.
И большой размер словаря тут не поможет.

Проблема gzip и bzip в том, что авторы уперлись в один алгоритм и не хотят ничего улучшать.

Автору 7zip большое спасибо за архиватор !

1. Твои эти различия между solid и не solid вполне дилетантские. Кто сказал, что надо чего-то там "сортировать по типу"? Нормальный архиватор разберётся и в tar-архиве, несмотря на то, в каком порядке там чего объединено. Взять тот же rzip.

> Проблема gzip и bzip в том, что авторы уперлись в один алгоритм и не хотят ничего улучшать.

Тебе слово "совместимость" ни о чём не говорит?

> Автору 7zip большое спасибо за архиватор !

+1, но только не надо говорить, что у gz или bz2 есть какие-то "проблемы". Людям нужна стабильность, часто она гораздо важнее тех дополнительных не очень больших процентов места на диске, которые можно сэкономить при переходе на новый архиватор. А учитывая соотношение процессорного времени к скорости сжатия, gz вообще вне конкуренции. Проц тоже знаешь не резиновый, особенно когда надо каждый день бэкапы делать.

> Чаще всего разные мажор версии библиотек несовместимы бинарно _и_ несовместимы по интерфейсам.

Я про это, между прочим, и написал :-/ И еще добавил, что пересобирать весь софт с новой либой неохота.

> Еще вариант stable и devel версии пакетов -- например ruby1.8 и ruby1.9. Т.е. это ситуация не нештатная, а обычная. Если разные версии одного проекта - могут быть установлены и развренуты как независимые пакеты - то это должно быть возможно сделать.

Я правильно понимаю, что в такой схеме можно забыть об автоматическом апгрейде ruby1.8 -> ruby1.9 (разумеется, со всеми модулями, установленными для старой версии)

> Чушь !

Попробуй что-нибудь упаковать tar-ом, а потом сжать tar-архив 7za с максимальным сжатием. Затем те же файлы упаковать в solid 7z архив. У меня и размер и время сжатия оказались примерно одинаковы. Проверял, правда, всего 1 раз.

>> По поводу пакетов с одним именем. Это полный бред, повторю еще раз. От этого одно зло. В debian sarge поставляется одновременно и apache 1.3 и apache 2.0. Первый пакет называется apache, второй apache2 - все апгрейды автоматически будут работать в одной ветке, так что apt-get dist-upgrade никогда не сменит major-версию продукта.

> Еще раз специально повторяю, медленнее... Да, установка двух пакетов разных версий - ситуация нештатная. Но иногда это требуется. Пример - когда библиотека меняет soname, а вытягивать обновления для всех пакетов, от неё зависящих _лично_ _мне_ и _прямо_ _сейчас_ по каким-то причинам лениво. Мэнтэйнер пакета не всегда в состоянии предугадать ситуацию, и дебиановское полиси относительно именования библиотек тут тоже не всегда помогает.Возможности rpm'а позволяют мне обойтись без тотального апдейта или самостоятельной пересборки, а возможности deb'а - нет.

Ты просто не понимаешь некоторых фанатиков Debian :)

Если какая-то возможность есть только в Debian - значит это супер-фича и ей надо гордиться. Если чего-то нет то это объявляется в лучшем случае никому не нужным, а чаще просто вредным багом :)

И так продолжается пока это не реализуют в Debian.

>Ты просто не понимаешь некоторых фанатиков Debian :) Если какая-то возможность есть только в Debian - значит это супер-фича и ей надо гордиться. Если чего-то нет то это объявляется в лучшем случае никому не нужным, а чаще просто вредным багом :) И так продолжается пока это не реализуют в Debian.

То же самое касается фанатиков Linux. И вообще, любых фанатиков.

> Я про это, между прочим, и написал :-/ И еще добавил, что пересобирать весь софт с новой либой неохота.

А я как раз про то написал, что пересобрать весь софт с новой либой получится далеко не всегда. Типичный пример - есть приложения на gtk-1, есть на gtk-2. Очевидно gtk-1 не собирутся с gtk-2, хоть ты их реж. И так же очевидно, что gtk-1 и gtk-2 могут необходимы обе в одной системе так как не все приложения перешли на gtk2.

> Я правильно понимаю, что в такой схеме можно забыть об автоматическом апгрейде ruby1.8 -> ruby1.9 (разумеется, со всеми модулями, установленными для старой версии)

Сам понял что сказал?

Представь пример: у тебя фабрика серверов и ты предоставляешь платный веб-хостинг с поддержкой какого-то языка. Например php4. У тебя есть сколько-то тысячь клиентов, у которых сайты работают на этом php4. Потом, в один прекрасный момент ты апргейдишь систему и весь php4 превращается в php5. После этого у 50% клиентов сайты работать перестают. Ты теряешь клиентов деньги и т.п., а все "от того, что в кузнице не было гвоздя".

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

А насчет автоматического апгрейда, то в debian он все таки есть. Через transition packages, которые по депендам удаляют старые пакеты и ставят новые. Но их нужно ставить сознательно.

Читаю как люди защищают rpm и просто плакать хочется... от смеха ;-)

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

Потому, что фичастый. Гораздо проще заменить крыло у самолёта-модели, чем у настоящего. dpkd прост как апельсин, со своими расширениями представляет из себя истинный unix-way, в отличие от монстрообразного "всё-в-одном" rpm.

> Возникают следующие вопросы, почему же все-таки каждое обновление(не

> enterprise, а порой и enterprise) дистрибутива, основанного на rpm, на

> следующую ветку делается только при помощи бубна и танцев?

Потому, что у тебя кривые руки? :-) FC1 -> FC3 -> FC5 -> FC6. Обновлялся без _каких бы то ни было_ малейших проблем. Инсталлер федоры последний раз видал года три назад.

Да и потом, когда обновляешь один дистрибутив с, например, php4 на другой, где php5, отваливаются скрипты, которые не совместимы с php5. А теперь, идиота кусок, задумайся, при чем тут RPM? :-) И перестань пердеть в лужу :-)

P.S. Кстати буквально на днях обновлял ASPLinux 10 до ASPLinux 11. 14 минут времени, всё прошло само, пока я пил чай и ел бутерброд с икрой. Так что иди почитай немного книжек, маны почитай, руки свои кривые вправь, посоветуйся с ближайшем гуру, может научат тебя на Linux работать.

> теперь, идиота кусок, задумайся... И перестань пердеть в лужу :-)

Видит Бог - я несколько лет не вступал в дисскусии на LOR. Спасибо, что напомнили, как приятно пообщаться с интелигентными людьми.

Ну да..... как жеж....

RH8 -> RH9 После обновления дистрибутив сдох просто

FC2 -> FC3 Тоже сдохло после обновления

FC3 x86_64 -> FC4 x86_64 После обновления сдохло также

ASPLinux 7.3 -> ASPLinux 9 Сдохло как и остальные

И это все не сразу после выхода дистрибутива в свет, а после выхода уже следующей его ветки. Если это фичастость rpm то фтопку такую фичастость. С dpkg таких проблем у меня никогда не возникало, а там я не только обновлялся, но и откатывался, и все без каких либо трудностей.

P.S. Slackware обновляется лучше чем ваше rpm-based ;-]

> RH8 -> RH9 После обновления дистрибутив сдох просто

> FC2 -> FC3 Тоже сдохло после обновления

> FC3 x86_64 -> FC4 x86_64 После обновления сдохло также

> ASPLinux 7.3 -> ASPLinux 9 Сдохло как и остальные

Ну что тут скажешь. За определенное количество $ в час я теоретически могу вправить руки наместо, но это сильно зависит от умственных способностей обучаемого :-) Повторюсь, обновление FC и ASP с версии на версию _работает_. А в кривых руках и калькулятор глючит.

>Ну что тут скажешь. За определенное количество

dmesg Потрясающий пример тупого упрямства и торжество фанатизма над жизненным опытом и здравым смыслом.

>FC3 x86_64 -> FC4 x86_64

я тоже проходил- долгая пляска с бубном

> Вот все говорят что rpm такой фичастый и т.д. и т.п. Возникают следующие вопросы, почему же все-таки каждое обновление(не enterprise, а порой и enterprise) дистрибутива, основанного на rpm, на следующую ветку делается только при помощи бубна и танцев?(прокомментируйте пожалуйста аргументированно, а не пердите в лужу что руки надо выпрямлять и т.д.)

Таки надо руки выпрямлять. Обновление делается apt-get update ; apt-get dist-upgrade

> dmesg Потрясающий пример тупого упрямства и торжество фанатизма

Я не пойму, это так проявляется зависть, что у меня Fedora без проблем обновилась? :-)

> я тоже проходил- долгая пляска с бубном

Родовая травма? :-) Могу вылечить. Либо за некоторое количество денег готов поддерживать твои серверы/рабочие станции. Я работы не боюсь. Зато ты можешь быть уверен, что всё будет работать. Либо могу предложить знакомых, которые могут взять на аутсорсинг твои ресурсы, если сам не умеешь администрировать Linux. Как говорится, бедность - не порок. В том числе бедность в знаниях.

> Представь пример: у тебя фабрика серверов и ты предоставляешь платный веб-хостинг с поддержкой какого-то языка. Например php4. У тебя есть сколько-то тысячь клиентов, у которых сайты работают на этом php4. Потом, в один прекрасный момент ты апргейдишь систему и весь php4 превращается в php5. После этого у 50% клиентов сайты работать перестают. Ты теряешь клиентов деньги и т.п., а все "от того, что в кузнице не было гвоздя".

"Абг'ам, этот гой будет учить нас коммег'ции!"

> А насчет автоматического апгрейда, то в debian он все таки есть. Через transition packages, которые по депендам удаляют старые пакеты и ставят новые. Но их нужно ставить сознательно.

Ну, собственно, ЧТД. Спасибо, что ответили на мой вопрос.

P.S. Прежде чем кидаться в бой строчить ответ (а, как я понял из предыдущего обсуждения, вы не очень долго раздумываете над доводами оппонента), перечитайте исходный вопрос, пожалуйста. А прочитав, ответьте на следующие вопросы: про апгрейд какого языка программирования я спрашивал? С какой версии на какую хотелось проапгрейдиться? Насколько безопасным с точки зрения обратной совместимости является такой переход? Заранее спасибо.

P.S.S. И, пожалуйста, не надо мне рассказывать о правилах апгрейда, принятых у мегахостеров. Если мне приспичит узнать эти правила, я их узнаю, можно сказать, из первых уст. Потому как часть моих соратников как раз и занимается тем, что апгрейдит, можно сказать, с соседнего рабочего места, таких вот мегахостеров.

> > То ли дело нам с apt

> Правильно, atp-*, aptitude и прочая появились от хорошей жизни и
> многих способностей dpkg ...

Ну, положим, оно точно так же и для rpm появилось...

> Посмотри топ дистрибутивов на ЛОР,

Там дистрибутивов не хватает. :-)

> Создание rpm т.е. spec файла к простому пакету это 3 минуты и 10 строк самого спека.

С deb'ами то же самое.

> С dpkg надо использовать кучу костылей (типа dh_make, dch,...) чтоб хоть как-то упростить работу. Да и все равно больше времени она занимает.

Можно не использовать. На худой конец, ar ещё никто не отменял.

deb

> Из-за пакетного менеджера?
ну вот я лично для себя перехожу на демьян в тоим числе из-за примущетсв deb перед rpm.

> но для меня как пользователя такая простая вещь как "sudo apt-get install nvidia-glx " весьма приятная штука и проблем с зависимостями я встречаю на порядок меньше с .deb чем с .rpm та достало уже по инету шарить в поисках пакетов для Mandriva и ASP

Бееедненький! А у меня драйвера для Nvidia на Mandriva 2007 Powerpack+ встали автоматом ещё при установке системы. :)

>Повторюсь, обновление FC и ASP с версии на версию _работает_.

А что такое "версия дистра"? ;) Я забыл уже, что бывает что-то кроме просто версий пакетов... :)

поверпак купил или украл?

> А что такое "версия дистра"? ;) Я забыл уже, что бывает что-то кроме просто версий пакетов... :)

А это то, для чего в sources.list[.d] не грех и новую запись добавить/старую отредактировать :-).

> поверпак купил или украл?

Честно купил: http://sibskull.livejournal.com/13019.html

>С dpkg таких проблем у меня никогда не возникало, а там я не только обновлялся

угу, помню-помню как после апдейта debian 2.2->3.0 приходилось плясать с бубном вокруг dpkg --install/dpkg --remove так как после какого-то очередного пакета apt-get впал в ступор и полезли неразрешаемые конфликты.

да какой там апдейт, 3.0r0 гладко не вставал там было несколько криво-собранных пакетов (xemacs и еще чего-то), ручками приходилось ссылки расставлять и dpkg запускать, так как хваленый apt-get не мог разрешить конфликт.

дома стоит Mandriva 2007 + пара пакетов из cooker. Обновлялось так 10.0->10.1->10.2 (2005)->2006->2007 ничего не умерло.

> дома стоит Mandriva 2007 + пара пакетов из cooker. Обновлялось так 10.0->10.1->10.2 (2005)->2006->2007 ничего не умерло.

Хе-хе. Пока сын не отформатировал дома диск, у меня там стояла система, полученная _плавным_ апгрейдом RH7 -> Mdk [сколько-то] -> ALT Linux (нескольких версий). Ну, да, некоторые переходы приходилось совершать, сжав зубы и держа наготове загрузочный диск ;-). Однако ничего, жив, не помер...

Эх, такая система была... Легендарная... А умерла совершенно нелепо. Я пластинку в приводе забыл, а сын с утра включил комп, увидел красивую заставку, и, не зная английского, начал на все вопросы отвечать "да", пока не дошел до места, где надо было что-то осмысленное в ответ сказать. Аккурат после того, как оно отформатировало / и /usr... Джидай, блин Хорошо еще, хоть /home по умолчанию не форматировался, так что материалы к кандидатской жены не померли...