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

Я изначально писал про «интерпрайз» и к вебу они отношения не имеет вообще.

Шо вы говорите. Если разбираться в этимологии, то enterprise = business. Иначе зачем мы тут все собрались? А business - это собрание людей, для предоставления товаров, услуг, сервисов. Почему вы вычёркиваете из этого веб - я не пойму. И тред вообще-то про веб-использование, я и был в этом контексте. Бизнес без веба, мне честно говоря и представить трудно, по крайней мере сегодняшний (чтоб вы понимали, веб для меня - это не только вебстранички). Разве что наши любимые госучреждения, да и те пытаются. А, ну производство ещё есть, космос, но там линукс идёт лесом.

Теперь представим, что библиотека libresolv.so.2 пеменяла so-name и ABI и стала libresolv.so.3.
Что происходит в Дебиане? Дебианщики ОБЯЗАНЫ изменить имя всего пакета

Двойка за знание матчасти. Марш читать debian policy.

Спойлер: имя пакета обязано измениться не при любом изменении ABI.

И что? Так уверены в неизменности ABI - пропишите версии «руками».

Вот. А на rpm руками прописывать не надо.

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

И пересобирать тоже.

Пишите в ЮНЕСКО, в ООН, на деревню дедушке. Дебиан-то тут каким боком?

Зачем, если в rpm этой проблемы не та вообще?

Спойлер: имя пакета обязано измениться не при любом изменении ABI.

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

Еще один со значком бубунты на чоле.

Вот. А на rpm руками прописывать не надо.

Ага. А еще там молочные реки и кисельные берега.

Зачем, если в rpm этой проблемы не та вообще?

Затем, что в rpm ровно те же яйца. Только в профиль.

Ни в одной системе разные ABI (обратно несовместимые) не суют в один пакет.

Я убунтой на серверах в целом доволен! Хотя есть и негативные моменты, которые в основном связаны с недостаточным опытом. Самое главное, что не нужно возиться с пакетами черт-пойми откуда и никаких kernel-panic! Кстати в SL 6 недавно обновлял ядро на hp 360g6 - заглючила атишная видюха - оказалось в пятой ветке баг не был закрыт за давностью, а в шестой еще не исправили - то же мне ынтырпрайз.

Ни в одной системе разные ABI (обратно несовместимые) не суют в один пакет.

В rpm не важно как называется пакет. Он может иметь другое имя или то же самое. Главное, что с новым пакетом будут нормально работать все старые программы, кроме тех, которым нужна изменившаяся библиотека. И не будут ругаться на зависимости.

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

Умница. После этого имеем два пакета библиотеки с несовместимыми ABI (и разными версиями). Пакеты, использующие старый ABI (т.е. старую версию библиотеки, старое имя) - ровно никакой пересборки не потребуют.

Теперь опишите ситуацию в RH.

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

Сюрприз! В Debian точно также.

Пересборки потребуют только пакеты, который перейдут на новую версию библиотеки с несовместимым ABI.

А что на вашем флаге?

После этого имеем два пакета библиотеки с несовместимыми ABI (и разными версиями).

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

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

Теперь опишите ситуацию в RH.

Просто повысится версия пакета и все. Все программы, кроме тех, которым нужна библиотека libresolv.so.2 будут работать нормально. Для тех, которым нужна эта библиотека можно будет сохранить в системе старую версию пакета с библиотекой, при этом большинство новых програм будет работать нормально и со старым пакетом.

> Убубу везде хренова. Хоть <...>, хоть на на десктопе.
Откровенная ложь. Использую убунту на домашней машине и на работе. Все отлично.

Я «бетатестер редхата» же.

А вот это врядли.

Так оно работает, извините. Мало-ли что вы себе нафантазировали... Смиритесь.

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

Стараются сделать именно так. Но иногда оставляют несколько версий. Например, вот: [code]ii libboost-python1.35.0 1.35.0-5 Boost.Python Library ii libboost-python1.42.0 1.42.0-4 Boost.Python Library[/code]

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

Учи уже матчасть.

Теперь опишите ситуацию в RH.

Просто повысится версия пакета и все. Все программы, кроме тех, которым нужна библиотека libresolv.so.2 будут работать нормально. Для тех, которым нужна эта библиотека можно будет сохранить в системе старую версию пакета с библиотекой, при этом большинство новых програм будет работать нормально и со старым пакетом.

Знакомьтесь, dll-hell - это Nxx. Nxx, знакомьтесь - это dll-hell.

Вместо троллинга - прочитайте раз debian policy. Помимо того, что вы узнаете то как на самом деле сделано - вы узнаете еще и то, почему сделано именно так.

Да я так говорю. И интерпрайз для меня это не веб. Ты привёл пример (задачу) с веб сервисом, и все хорошо разложил и деньги прикинул (ubuntu сервер бесплатен как оказалось) и т.д.

Теперь моя задача, горнолыжный центр надо настроить всю инфраструктуру, начиная от считывателей карточек на подъёмник и заканчивая кассовыми аппаратами в кафешке, да и с тем же веб сервисом новости, личные кабинеты, ну ещё плюсом онлайн бронирование и оплата. Вот тут лично я canonical не доверюсь ни как вы уж извините (кроме облаков писаных на python и чего там ещё и не дорогой поддержкой они меня не удовлетворят), делать решения от microsoft в принципе можно но цена будет заоблачной. Так что red hat со своими решениями будет очень кстати.

ЗЫ И графики от W3Techs к рынку крупных промышленных систем отношения не имеют никакого, только если в мечтах Шаттлворта.

И кстати enterprise это задачи на уровне предпрития а не business`а, если уж вдоватся в этимологию.

И интерпрайз для меня это не веб.

Вообще-то у редхата всегда упор шёл на веб и database. Потом пошли сервера приложений (jboss) и виртуализация для гибкости руления этим делом. Спорить тут нет смысла, достаточно глянуть на список пакетов в дистре и офиц. доки. Одного perl'a и php там треть дистра.

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

Уж думал, что вы щас будите про опсосов с ихней соляркой или ERP'шки без веб-сервисов с 20к клиентами и ораклом ). Я бы на вашем месте тоже делал на редхате ;)), если его готовы каждый год покупать. Для такой задачи преимущества убунты невилируются, срок поддержки ОС, поддержка оборудования будет рулить.

Я не ратовал «за» убунту всегда и везде. Просто есть тренд и списывать его со счетов не стоит.

А если B2B? И там через вебсервисы перекачиваются терабайты данных, из которых формируются сотни прайсов, с 170-250k ценами в одном. Сплошные вебсервера и базы данных. Про которые CEO не в зуб ногой в IT, ведут между собой встречи, типо протокол какой юзать и продвигать и т.д.. Где тут заканчивается enterprise и начинается business? Наверное при попилке зарплат )).

В rpm-based эта проблема решена, а в dpkg - нет

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

С rhel (точнее с линукс) вас бы близко не подпустили. rhel был только на коммерческой рассылке (по скромному, 200-500k emails/day, 200-300kb/email).

Привел пример и сам его опроверг. :)

А админа с эникеем не путаешь ? :-)

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

Сам себя я не опровергал. Разговор раздвоился на rhel vs ubuntu и «шо такое энтерпрайз». Моя мысль была, что энтерпрайз в IT это не rhel с ораклом и джавой, а некий набор программно-аппаратных средств решающих бизнес-задачи предприятия, работающий безперебойно, качественно. И это может быть обычный LAMP (не многие на самом деле умеют 99,999% uptime) или что-то другое, но и убунта имеет свою нишу и право на жизнь.

Но как он может решить что мне лучше подходит для проекта?

Решают CTO или CIO, а в них бывают вырастают админы. Так что ).

В rpm-based эта проблема решена, а в dpkg - нет

Которая «проблема»? Я наблюдаю лишь одну проблему: незнание матчасти, которую пытаются «критиковать».

Шаттлворт добазарился с дэбианщиками о том, чтобы они сократили сроки поддержки, дабы переманить часть аудитории на Ubuntu Server. Как пить дать.

Ну так объясни в чем я заблуждаюсь. Пока я вижу, что не знаешь матчасть ты.

И что? Так уверены в неизменности ABI - пропишите версии «руками».

смена ABI == смена числа после .so. rpm дает эту уверенность без прописывания версии руками, к нумерации пакета это никакого отношения не имеет и завязываться на имя/номер пакета - ошибка

Стараются сделать именно так. Но иногда оставляют несколько версий.

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

Знакомьтесь, dll-hell - это Nxx. Nxx, знакомьтесь - это dll-hell.

Давай поставим эксперимент. Ты сможешь на последнюю Убунту поставить Gnome2 без пересборки?

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

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

Давай поставим эксперимент. Ты сможешь на последнюю Убунту поставить Gnome2 без пересборки?

Как только ты придумаешь осмысленный эксперимент. Не включающий в себя убунту (с которой я мало знаком) и идиотские задачи.

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

Ну значит, там нет библиотек с общим именем, т.е. ABI все библиотек изменился одновременно. Мы ведь не об этом случае говорим.

Как только ты придумаешь осмысленный эксперимент. Не включающий в себя убунту (с которой я мало знаком) и идиотские задачи.

Ну поставь Gnome 2 на Wheezy. Что тут идиотского?

Ну так объясни в чем я заблуждаюсь.

В том что не удосужился заглянуть в debian policy и посмотреть как именно сделано и почему.

смена ABI == смена числа после .so. rpm дает эту уверенность без прописывания версии руками

Да ну :) Все также будешь прописывать BuildRequires и указывать конкретные версии (минимум, к примеру) либы. Тебя удивит, но для мейнтейнера debian - все точно также.

То что в новом релизе при смене ABI могут заставить заменить в build-depends libfoo1-dev (>= 1.1.0) на libfoo2-dev (>= 2.3.0) - так это здорово. А ты бы предпочел, чтобы в системе оставалось надцать неподдерживаемых версий одной и той же библиотеки?

Не надо в дебиан такого «интерпрайзу», ага? У пакета в релизе либо есть мейнтейнер, который ответственен и за обработку transition в дистрибутиве (в т.ч. убирание зависимостей от устаревших либ) - либо оный пакет нафиг не нужен.

Ну значит, там нет библиотек с общим именем, т.е. ABI все библиотек изменился одновременно. Мы ведь не об этом случае говорим.

А о каком? Что за «библиотеки с общим именем», у которых вдруг разный ABI?

Это нонсенс. Пакет логически содержит одну библиотеку (не важно сколько там so-шек), в отношение этого пакета в целом имеет смысл вести разговор о смене ABI.

Да ну :) Все также будешь прописывать BuildRequires и указывать конкретные версии (минимум, к примеру) либы. Тебя удивит, но для мейнтейнера debian - все точно также.

Нет, всё по другому. Я пишу в spec в BuildRequires: libfoo-devel >= 1.1.0 При этом у меня сгенерится _одинаковая_ зависимость при компиляции и на 1.1.0 и на 1.1.1 и на 1.1.100500, так как ABI не поменялся, а в дебобунте зависимость будет _другая_.

А ты бы предпочел, чтобы в системе оставалось надцать неподдерживаемых версий одной и той же библиотеки?

Их там уже есть, например, в том же wheezy 3 (!!!) версии буста.

Админ знает как сопровождать.

И только ? Всё же, эникей... Для сопровождения достаточно инструкции.

Но как он может решить что мне лучше подходит для проекта ?

А как может решить, что подходит для проекта тот, кто не представляет, как это всё работает ?

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

Такие проекты завершаются, как прочие другие начинания «эффективных менеджеров».

Что тут идиотского?

Попробуй головой думать.

Нет, всё по другому. Я пишу в spec в BuildRequires: libfoo-devel >= 1.1.0 При этом у меня сгенерится _одинаковая_ зависимость при компиляции и на 1.1.0 и на 1.1.1 и на 1.1.100500, так как ABI не поменялся, а в дебобунте зависимость будет _другая_.

Неправда. Посмотри, пожалуйста, как на самом деле.

А ты бы предпочел, чтобы в системе оставалось надцать неподдерживаемых версий одной и той же библиотеки?

Их там уже есть, например, в том же wheezy 3 (!!!) версии буста.

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

А о каком?

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

Пакет логически содержит одну библиотеку (не важно сколько там so-шек), в отношение этого пакета в целом имеет смысл вести разговор о смене ABI.

libboost - исключение. Там и правда только одна библиотека в пакете. Но это не так для многих других библиотек (glibc, kdelibs, qt, cups, gtk)

Нет, всё по другому. Я пишу в spec в BuildRequires: libfoo-devel >= 1.1.0 При этом у меня сгенерится _одинаковая_ зависимость при компиляции и на 1.1.0 и на 1.1.1 и на 1.1.100500, так как ABI не поменялся,

Причем, пакт будет работать и с более ранними версиями libfoo, если ABI не поменялся.

Попробуй головой думать.

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

Во имя великого Марка, прошу тебя - сделай это!

Пакет логически содержит одну библиотеку (не важно сколько там so-шек), в отношение этого пакета в целом имеет смысл вести разговор о смене ABI.

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

Ты вообще читать умеешь?

libc как раз пример того, как в одном пакете собраны несколько so. Но говорить об изменениях ABI по-отдельности - будет интересно только авторам libc. Все остальные это пользуют целиком. Потому и не подробили на десяток пакетов.

Причем, пакт будет работать и с более ранними версиями libfoo, если ABI не поменялся.

Добро пожаловать в dll-hell и кунсткамеру уязвимостей. Или какой-то добрый дядя будет продолжать сопровождать античные версии библиотек, которые вы однажды себе понаставили?

Просто поймите, пожалуйста, что подход, избранный RH - не идеальный и даже не лучший. Он лучше подходит для дистрибутива а-ля RHEL/CentOS: штатного ПО с гулькин нос, плюс стороннее коммерческое ПО без исходного кода и десяток «левых» репов разной степени паршивости для открытого ПО.

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

Нет. Потому что никто не будет тратить время на подобный эксперимент просто ради прихоти пионера.

Все остальные это пользуют целиком.

Неправда.

У меня количество пакетов, требующих libresolv НАМНОГО меньше количества пакетов, требующих libc.

Нет. Потому что никто не будет тратить время на подобный эксперимент просто ради прихоти пионера.

Я тебе, дядя, не пионер.

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