Ubuntu наращивает долю на рынке крупных промышленных систем

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

Спеки можно писать кросс-дистрибутивные. Форматы сжатия одинаковые.

Установочные скрипты вообще используются очень редко.

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

На сусе ставил пакеты от альта, федоры и мандривы.

А вообще, если пакет соответствует спецификации LSB, он должен встать на любой дистрибутив.

Файловых зависимостей там нет.

Да, уже написал - выше ткнули носом, увлёкся, перепутал.

жесть

Я наркотики вообще никому не рекомендую.

Если не считать Suse, которая раньше базировалась на RedHat

Сходи в википедию хотя бы.

На сусе ставил пакеты от альта, федоры и мандривы.

Практически то же самое, только на федоре ставил пакеты из мандривы, альта и пару раз из сусе. Так что в этом полностью согласен.

> А в новости, кажется, и не указано, что оно независимое. :)

Это указано в комменте, на который я отвечал.

чушь - потому что лично ты не согласен с реальным положением вещей?

Тогда это фантазия комментатора. :)

Да, пельменный бог тебя попутал :)

Комментатор и автор новости - одно лицо :)

Вот ведь чего вспомнил, а... Ну и память у тебя. :)

А кто-нибудь скажет, какие ккрупные компании отказались от RHEL в пользу бубунты? А то, что Марк вбросил без пруфов, что опеннет перепостил, что тут на ЛОРе как обычно на отвлечённые темы холивары идут. Где посмотреть список этих крупных промышленных решений на бубунте?

Файловых зависимостей в deb нет? Ты мне Америку сейчас открыл. То есть установщик Дебиана мне врал... :)

В Дебиане зависимости по пакетам, а не по файлам. В rpm пакете есть список библиотек, с которыми слинкованы бинарники, содержащиеся в пакете. Например, «libastral.so.0.4 (libastral 3.0 64-bit)» И если ты хочешь установить пакет, пакетный менеджер просматривает все пакеты и ищет, где есть этот файл. Пакет просто не установится, пока все слинкованные библиотеки не будут найдены в зависимостях.

В deb-пакетах зависимости содержат только имя пакета с зависимостью. То есть, там будет просто написано «libastral». А в пакете libastral может быть библиотека совсем с другим ABI. Или вообще имена пакетов случайно сопадают.

Причем rpm правильно пропишет зависимости деже если ты сделаешь rpm-пакет из бинарного тарбола утилитой alien. А вот на дебиане alien создает пакеты вообще без зависимостей.

Марк зря старается. Бесполезно что-либо доказывать убунтоненавистникам. Они неадекватны.

Я знаю. Тогда он ещё и большой хитрец - в новости не написал, чтобы «не дёргать котов/тигров за усы», а в комментах втихаря начал двигать идею «независимого исследования». :)

Кстати, тут я вспоминаю недавнюю новость, что из Kubuntu отзывают _единственного_ оплачиваемого мантайнера от каноникал, что курировал разработку :) Как это понимать на фоне остальных побед не ясно.

Ну я это понимаю так, что люди в сообществе Дебиана трудятся, а Марк на их фоне пиарится.

Ок, ок, но вот если бы все дистрибутивы приняли этот формат пакета, то он бы стал стандартом и «де-юре», и «де-факто». Но пока этого не наблюдается...

Благодаря Марку.

В Дебиане зависимости по пакетам, а не по файлам.

Да всё уже, претензия снята. В третий раз - уже выше ткнули носом, увлёкся, перепутал. «Что ж мне теперь, самому что ли зарезаться перед вами, папаша, чтобы вы мне поверили?» :)

В deb пакетный менеджер не знает ничего про библиотеки, а знает только про пакеты. Если ты собираешь пакет на системе с libwtf_1.0.0-2, то ты уже его не сможешь поставить на систему с libwtf_1.0.0-1 и не важно, что между -1 и -2 поменялся только postinst скрипт :)

Во-первых, там дробление не по номеру сборки, а по версии пакета, во-вторых, пакеты в репозитарии консистенты. А в rpm системах тебе придётся зато руками симлинки с libwtf_1.0.0 на libwtf_1.0.0-2 делать.

Ну то есть преимущество в том, что путь решения проблемы бэкпортов другой — это не преимущество.

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

Согласен с этим. Попробовать хотя бы несколько дистрибутивов Linux, и только поле этого делать о них выводы. Однако есть много людей, которые пробовали только один, а уже думают плохое про другие. Это те, кто спрашивали «а что такое su?» в недавней новости про уязвимость в sudo, также очень много таких людей встречал на сайте http://liberatum.ru/ - причём там такие люди даже не комментаторы. Зачастую авторы новостей. http://liberatum.ru/blog/samyi-luchshii-distributiv http://liberatum.ru/forum/postavil-linux-—takogo-derma-eshche-ne-videl-chto-ya-sdelal-ne-tak

Спеки можно писать кросс-дистрибутивные. Форматы сжатия одинаковые.

Можно. Можно даже OBS использовать. Но причём тут rpm?

Форматы сжатия одинаковые.

Да щаз. Про rpm4/rpm5 ты хотя бы в курсе?

А вообще, если пакет соответствует спецификации LSB, он должен встать на любой дистрибутив.

На любой LSB-совместимый. Спецификация LSB сильно сужает rpm до конкретных версий спеков, сжатий и т.п.

Впрочем beb-пакты из убунты в дебиан тоже ставятся, что с того? )

Файловые зависимости это недостаток, блджад!

Ну вообще говоря, внутрь этого «патча» можно запихать так называемые dpatch'и, которые идут раздельно. Кстати, формат dpatch'а несовместим с обычным patch'ем и создать его можно только утилитой dpatch, поэтому поддерживать такое говно то еще развлечение :)

Я такого не видел. И вот, кстати, примерчик. Поскольку Trinity десктоп создавался на основе убунтовских патчей к КДЕ3, а отделить убунтоспецифичные патчи от других в дебовском пакете не реально, то вот такие забавные фрагменты можно увимдеть среди коммитов в Trinity:

diff --git a/kcontrol/kdm/kdm-appear.cpp b/kcontrol/kdm/kdm-appear.cpp
index 684371d..7d1d034 100644
--- a/kcontrol/kdm/kdm-appear.cpp
+++ b/kcontrol/kdm/kdm-appear.cpp
@@ -442,7 +442,7 @@ void KDMAppearanceWidget::load()
   config->setGroup("X-*-Greeter");
 
   // Read the greeting string
-  greetstr_lined->setText(config->readEntry("GreetString", i18n("Welcome to %s at %n")));
+  greetstr_lined->setText(config->readEntry("GreetString", i18n("Welcome to Kubuntu at %n")));
 
   // Regular logo or clock
   QString logoArea = config->readEntry("LogoArea", "Logo" );
@@ -485,7 +485,7 @@ void KDMAppearanceWidget::load()
 
 void KDMAppearanceWidget::defaults()
 {
-  greetstr_lined->setText( i18n("Welcome to %s at %n") );
+  greetstr_lined->setText( i18n("Welcome to Kubuntu at %n") );
   logoRadio->setChecked( true );
   slotAreaRadioClicked( KdmLogo );
   setLogo( "" );

@@ -2044,9 +2050,9 @@ Description:
 
 Key: GreetString
 Type: string
-Default: "Welcome to %s at %n"
+Default: "Welcome to Kubuntu at %n"
 User: greeter
-Instance: #*/"K Desktop Environment (%n)"
+Instance: #*/"Welcome to Kubuntu at %n"
 Comment:
  The headline in the greeter. The following character pairs are replaced:
  - %d -> current display

и т.д. http://www.trinitydesktop.org/patches/1260562887:10e41144596fc9ced40fc349d9ec...

А потом это все годами вычищать.

Во-первых, там дробление не по номеру сборки, а по версии пакета

_полной_ версии вместе с номером сборки, то есть зависимость будет от libwtf (>= 1.0.0-2).

во-вторых, пакеты в репозитарии консистенты.

в rpm тоже консистентны, но deb будет мне каждый раз предлагать обновить чуть ли не весь дистрибутив

А в rpm системах тебе придётся зато руками симлинки с libwtf_1.0.0 на libwtf_1.0.0-2 делать.

Наглое 4.2 и феерические незнание матчасти. В rpm пакет привязывается к _библиотеке_, а не к пакету, поэтому если изменится версия библиотеки (числа после .so), то будет установлен по зависимостям новый пакет.

феерично

В deb-пакетах зависимости содержат только имя пакета с зависимостью. То есть, там будет просто написано «libastral». А в пакете libastral может быть библиотека совсем с другим ABI. Или вообще имена пакетов случайно сопадают.

Вот это не надо. Там прописываются версии пакетов, а именование пакета строго зависит от версии библиотеки в нём. Таким образом, если указано в Depends libastral (>= 3.0), это значит, что подойдёт любой пакет с версией библиотеки выше или равно 3.0. Если указано (>= 3.0-2), то значит версия библиотеки должна быть не меньше 3.0, а версия deb-пакета при этом 2 или выше. Это в кратце, там с версиями намного больше возможностей.

Вы или давно не работали с deb-пакетами, или просто наговариваете.

В rpm пакет привязывается к _библиотеке_, а не к пакету, поэтому если изменится версия библиотеки (числа после .so), то будет установлен по зависимостям новый пакет.

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

_полной_ версии вместе с номером сборки, то есть зависимость будет от libwtf (>= 1.0.0-2).

Знак >= ни о чём не говорит?

Наглое 4.2 и феерические незнание матчасти. В rpm пакет привязывается к _библиотеке_, а не к пакету, поэтому если изменится версия библиотеки (числа после .so), то будет установлен по зависимостям новый пакет.

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

Я такого не видел.

dpatch'и очень сложно создавать и поддерживать, вместо того чтобы сделать svn/hg/git diff > 001-patch.patch и вписать в .spec Patch0: 001-patch.patch я должен совершать последовательность сложных магических действий, поэтому с этим мало кто заморачивается.

Пакетный менеджер не знает, какая библиотека конкретно нужна данному пакету

А теперь добавляем лулзов. Пакетный менеджер знает какой файл нужен пакету. А где его взять? Если в подключенных репах пакета с файлом нет? Сколько раз на такое натыкался. Приходится гуглить название пакета по файлу чтобы по названию пакета найти незнамо где и подключить незнамо какую репу. Ахрененно удобно.

во-вторых, пакеты в репозитарии консистенты.

Вот именно, что только в одном репозитории. А шаг в лево, шаг в право - расстрел.

А в rpm системах тебе придётся зато руками симлинки с libwtf_1.0.0 на libwtf_1.0.0-2 делать.

Какие симлинки? Если пакеты различаются только скриптом, а файлы библиотек там одинаковые, то все будет работать отлично.

Если нужного файла с библиотекой нет, то зависимости просто не будут удовлетворены.

Знак >= ни о чём не говорит?

Говорит о том, что ко мне в систему потянется эта библиотека, хотя между -1 и -2 из изменений только строка в README. Я не хочу такого идиотизма.

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

Какой симлинк? Зачем? Ты сам то понимаешь что говоришь?

Вот именно, что только в одном репозитории. А шаг в лево, шаг в право - расстрел.

А для этого и есть pin-priority. Ну что, у кого костыли длиннее?

Если нужного файла с библиотекой нет, то зависимости просто не будут удовлетворены.

Вот именно, а если нужный файл в другом репозитарии?

Это указано в комменте, на который я отвечал.

Я имел ввиду независимость статистических подсчетов W3Tech, возможно не так выразился. Мнение Марка конечно зависимое, ну и так понятно. Как у Марка может быть полностью независимое мнение об Ubuntu? А у Поттеринга о systemd тоже независимое? Так что его не слушать вообще? Тем не менее он привел какие-то ссылки, «проанализировал». То есть не тупой вброс и пиар, как некоторые пытаются представить.

Говорит о том, что ко мне в систему потянется эта библиотека, хотя между -1 и -2 из изменений только строка в README. Я не хочу такого идиотизма.

Если сборщик пакет не идиот, он не будет в зависимостях указывать полную версию пакета, благодаря чему системе подойдёт и -1, и -2.

Одно ядро, один дистрибутив, один вождь, ну же.

Пакетный менеджер знает какой пакет нужен пакету. А где его взять? Если в подключенных репах пакета нет? Сколько раз на такое натыкался. Приходится гуглить название пакета чтобы по названию пакета найти незнамо где и подключить незнамо какую репу. Ахрененно удобно.

fixed

Пакетный менеджер знает какой файл нужен пакету. А где его взять? Если в подключенных репах пакета с файлом нет? Сколько раз на такое натыкался.

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

Тем не менее он привел какие-то ссылки

Ссылки на крупные компании ушедшие с RHEL на бубунту таки будут или нет?

Руками зависимости никто не указывает, их может быть 100500 и они могут вести к _разным_ _пакетам_ (привет дебиановскому ноухау - бусту с вкоряченной версией :) ) Зависимости генерятся с помощью dh_makeshlibs

> То есть не тупой вброс и пиар, как некоторые пытаются представить.

Хорошо - это умный вброс и пиар. Но ИМХО это не повод его тащить на ЛОР.

Убунта обогнала красношляпу, это уже интэрпрайз.

ЛОР на Федорке крутится, так что мы сейчас на сайте садомазохистов.

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

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

это почему же?

Знак >= ни о чём не говорит?

Говорит, что это гадание на кофейной гуще. Мейнтейнер надеется, что его программа будет работать со всеми последующими версиями пакета с таким именем, надеясь на обратную совместимость.

А если обратной совместимости нет, то пакетный менеджер не сообщит о проблеме, а программа работать не будет.

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

Это понятно. Но никто не мешает в случае чего подправить. Я у себя в системах при сборке пакета как раз руками правлю зависимости, благодаря чему мои пакеты становятся и на чистый stable, и на stable c бекпортами, и на testing. Честно скажу, с rpm я знаком только на уровне пользователя, но в debian'е это рулится очень легко.

Ubuntu 18.4%

Вот о чем Кэмерон в Терминаторе предупреждал! ;)