В списке рассылки debian-project Марк Шатлворт опубликовал письмо (http://lwn.net/Articles/345353/), в котором изложил свою точку зрения на взаимодействие между различными дистрибутивами, и насколько позитивным такое сотрудничество может быть для независимых разработчиков ПО и конечных пользователей.«<i>...Представьте, что вы лидер ключевого программного (upstream) проекта. Вам не безразлично мнение ваших пользователей, вы хотите, чтобы они ценили программы, которые вы разрабатываете. Но вы также понимаете, что основная масса пользователей получит ваш код не напрямую от вас, а посредством одного из дистрибутивов, будь-то RHEL, Fedora, Debian, Ubuntu или Gentoo... Хуже всего, то что в одно и то же время разные дистрибутивы могут включать совершенно разные версии вашего кода. Такое положение дел затрудняет поиск и исправление багов, и из-за этого трудно определиться, на какой версии нужно сконцентрироваться, чтобы довести ее до стабильного состояния</i>».
Абзац, процитиро...
URL: http://lwn.net/Articles/345353/
Новость: http://www.opennet.me/opennews/art.shtml?num=22904
Не обращайте внимания. Это у него перед LTS. Как только выпустят - и мета-циклы пройдут, и это тоже, и всё остальное.
А вот мне представляется, что идея здравая. Ведь такой зоопарк дистрибутивов действительно усложняет жизнь разработчикам.
Этот зоопарк дает свободу выбора.
Если все децентрализованая система более устойчивая.
Космонавт просто решил возглавить
>Этот зоопарк дает свободу выборасвободу выбора между потерянным временем, потерянными деньгами и испорченными нервами
Врал бы он меньше и не лепил "благ сообщества" поверх своих собственных, вот что.А то за выжигание разработчиков и разевание пасти ещё и на апстримы со своими дебильными полугодовыми циклами для всех -- на гауптвахту бы, по-хорошему.
>Врал бы он меньше и не лепил "благ сообщества" поверх своих собственных, вот что.ты неадекват?
достоинства
а) меньше поддержки легаси версий, разработка новых версий с учётом версий стабильных либ только одной версии. Сейчас это актуально для стабильных дистрибутивов, куда новое по из-за зависимостей иногда не могут быстро бэкпортировать.>дебильными полугодовыми циклами для всех
lts гораздо реже, соответственно и релиз может быть при данных циклах в пределах плюс/минус по полгода, в зависимости от тестирования. Кстати, и бэкпортировать что-то новое на стабильную основу будет легче, если все будут придерживаться совместимости со стабильными версиями.
>циклами для всех
никто не ждёт одного пакета, и никто не подстраивается под релизы всех дистрибутивов. Многим бы не помешал ориентир, когда желательно выпускать стабильную версию.
И что в итоге? Кто хочет, тому легче сделать и поддерживать стабильную вервию, кому это не нужно, что изменилось?
>lts гораздо реже, соответственно и релиз может быть при данных циклах в пределах плюс/минус по полгода, в зависимости от тестирования. Кстати, и бэкпортировать что-то новое на стабильную основу будет легче, если все будут придерживаться совместимости со стабильными версиями.Вы про bleeding edge дистрибутивы слышали?
Вы про git clone слышали?
>>Врал бы он меньше и не лепил "благ сообщества" поверх своих собственных, вот что.
>ты неадекват?Я не понаслышке знаю о том, как создаются и поддерживаются команды и дистрибутивы. И уже достаточно пообщался с sabdfl.
Если не расплодилось анонимов под одной кличкой "Имя", то судя по остальным комментариям -- Вам лучше не мне такие вопросы задавать, а зеркалу.
И ещё: с Вами, милейший, на брудершафт вроде как не пили.
>достоинства
>а) меньше поддержки легаси версий, разработка новых версий с учётом версий стабильных
>либ только одной версии. Сейчас это актуально для стабильных дистрибутивов, куда
>новое по из-за зависимостей иногда не могут быстро бэкпортировать.Можете не рассказывать, с этим я тоже знаком не понаслышке. Нет, это не достоинство, но объяснение Вам, скорее всего, не понять (и на него уйдёт довольно много времени).
>>дебильными полугодовыми циклами для всех
>lts гораздо реже, соответственно и релиз может быть при данных циклах в
>пределах плюс/минус по полгода, в зависимости от тестирования.Я не про LTS (или то, что у других содержит буковку "E"). Я про выжигание замечательных людей безмозглым и бессовестным менеджментом. Есть примеры, к сожалению.
>Кстати, и бэкпортировать что-то новое на стабильную основу будет легче,
>если все будут придерживаться совместимости со стабильными версиями.К сожалению, stable vs development -- это tradeoff, который не всегда удаётся разумным образом решить компромиссно вследствие архитектурных упущений в этих самых стабильных версиях. Хорошо бы не ошибаться, но людям это свойственно.
>>циклами для всех
>никто не ждёт одного пакета, и никто не подстраивается под релизы всех
>дистрибутивов. Многим бы не помешал ориентир, когда желательно выпускать
>стабильную версию.Я как участник разработки дистрибутива Linux, а также порой встревающий в разработку различных upstream -- ответственно заявляю: а многим он _мешает_. Потому как Шатлворт не собирается никого слушать, кроме себя. Он D, в конце концов, или где?
>И что в итоге? Кто хочет, тому легче сделать и поддерживать стабильную
>вервию, кому это не нужно, что изменилось?Вы руками не размахивайте, а пойдите поделайте что-нить полезное. Несколько лет хотя бы. А потом милости просим возвращаться к обсуждению того, что такое хорошо, а что такое плохо. При делании, а не размахивании.
>Я не понаслышке знаю о том, как создаются и поддерживаются команды и дистрибутивы.А Марк не знает?
>Нет, это не достоинство, но объяснение Вам, скорее всего, не понять (и на него уйдёт довольно много времени).
>Потому как Шатлворт не собирается никого слушать, кроме себя.И правильно сделает. Прислушиваться к другим надо, когда они что-то полезное говорят.
>К сожалению, stable vs development -- это tradeoff, который не всегда удаётся разумным образом решить компромиссно вследствие архитектурных упущений в этих самых стабильных версиях.
Значит ПО ещё не готово, если нет вменяемого стейбла.
>>Я не понаслышке знаю о том, как создаются и поддерживаются команды и дистрибутивы.
>А Марк не знает?Знает, конечно. Это замечание было к Вам, который явно не знает.
>>Потому как Шатлворт не собирается никого слушать, кроме себя.
>И правильно сделает. Прислушиваться к другим надо, когда они что-то полезное говорят.Они-то как раз говорят. Почему не слышит -- не знаю, мож звёздная хапнула.
>>К сожалению, stable vs development -- это tradeoff, который не всегда удаётся
>>разумным образом решить компромиссно вследствие архитектурных упущений в этих
>>самых стабильных версиях.
>Значит ПО ещё не готово, если нет вменяемого стейбла.Примеров "готового" ПО знаю совсем немного -- как тот же TeX. И то в стане макропакетов выше его готовностью близко не пахнет.
Вы или перфекционируете, или опять не понимаете вообще предмет обсуждения.
ПО -- это очень ярко демонстрирующая несовершенство и бурность нашего мира его часть. Вследствие нематериальности слишком сильно провоцирует отношение "спустя рукава", хотя результаты порой оказываются опаснее, чем если бы были халатно отлиты в чугуне и подлежали обработке настоящим стальным напильником.
Так вот когда до разумных и толковых разработчиков доходит комплекс проблем, нерешаемый в рамках имеющейся архитектуры -- подчас начинают и full rewrite. При этом ценность первых итераций (веток) оказывается даже не в продукте вроде KDE 1.x, а в наработке команды и опыта.
Мне вот однажды по производственной необходимости довелось наткнуться на патчик для добавления n-up (кол-во страниц на лист) в диалог печати то ли Qt 2.x, то ли KDE 2.x. Пытаться портировать его на современные версии смыслу имело мало, пытаться задействовать те древние -- смыслу не было вообще. Но это не имело отношения к "готовности" что 2.x, что 4.x.
>Знает, конечно. Это замечание было к Вам, который явно не знает.Ну-ну. Поделки которые постоянно ломают не нужны.
>Почему не слышит -- не знаю, мож звёздная хапнула.
Говорят, про строгое следование графику выпуска с точностью до месяца. О чем говорить, если некоторые не различают релиз и заморозку.
>Примеров "готового" ПО знаю совсем немного -- как тот же TeX.
Готовое это не идеальное, а то, которое выполняет свои задачи. Соответственно и скачков в развитии там нет. Так что на новую версию стоит посмотреть через несколько лет. Еще раз, если ПО через несколько месяцев внезапно сильно меняется, то оно либо не готово, либо просто поделка, либо кто-то сделал новый функционал, который для большинства текущих пользователей не критичен.
>Вы или перфекционируете, или опять не понимаете вообще предмет обсуждения.
Нет, апгрейдиться на каждую новую версию неразумно в большинстве случаев. Любое серьёзное решение - только стейбл в основе.
>При этом ценность первых итераций (веток) оказывается даже не в продукте вроде KDE 1.x, а в наработке команды и опыта.
Судя по кде4, которые на куте и плюсах с 10000(писец) багов, ценность в данном случае нулевая.
>Так вот когда до разумных и толковых разработчиков доходит комплекс проблем, нерешаемый в рамках имеющейся архитектуры -- подчас начинают и full rewrite
Разные вещи. Полное переписывание займёт несколько лет. Если проект нормальный, то старую вектку будут поддерживать, поскольку она полезна. Если проект кде, то всё забросят, а в итоге даже через несколько лет ничего вменяемого не сделают. В данном случае будет легче - есть одна легаси версия и всё.
>Мне вот однажды по производственной необходимости довелось наткнуться на патчик для добавления n-up (кол-во страниц на лист) в диалог печати то ли Qt 2.x, то ли KDE 2.x.
Совсем не тот случай, это давно не поддерживаемой софт. Например, нужно стабильное кде4, но и нужна новая версия некоторого компонента кде4. Вот и нужно апгрейдить всё кде и половину системы. Сейчас об этом никто не задумывается даже. Если был бы какой-то единый ориентир, то может бы задумывались. Опять профит.
>Ну-ну. Поделки которые постоянно ломают не нужны.В недавнем релизе Xorg что-то поломалось с карточками intel, выбросите xorg как ненужную поделку?
>выбросите xorg как ненужную поделку?не смею и мечтать
>В недавнем релизе Xorg что-то поломалось с карточками intel, выбросите xorg как ненужную поделку?там для интела столько вариантов сделали через что работать и как ускорять. кстати, а из-за кривого драйвера линукс, бзд и т.д. тоже выкинем?
очнулись.
в последних версиях осталась только uxa.
ps:
у кого как, а у меня не поломалось, а исправилось. (xorg 1.6.3 и ядро должно быть >= 2.6.30)
>Я про выжигание замечательных людей безмозглым и бессовестным менеджментом.Боюсь, ^^--англицизм не будет понятен оппонентам, не прошедшим ценз владения английским и некоторым языковым опытом. А точного и короткого перевода "burnt-out", наверное, нет.
burned-out \burned-out\ burnt-out \burnt-out\adj. prenom.
1. drained of energy or effectiveness; driven to apathy by
overwork or prolonged stress; -- of people.
...
burn out \burn out\ v. i.
...
3. To become apathetic or depressed, and cease to function
effectively, due to the fatigue and frustration of
prolonged stress and overwork; -- of people; as, the
stress in the bond market is so great that many traders
burn out after only ten years on the job.
[PJC]
>>Я про выжигание [...] людей
>Боюсь, ^^--англицизм не будет понятен оппонентам, не прошедшим ценз владения
>английским и некоторым языковым опытом. А точного и короткого перевода "burnt-out",
>наверное, нет.Тут чуть хуже -- слово "выгорание" скорее было бы понятно вследствие "гореть на работе"; но требовался не пассив, а актив впридачу.
Раньше тоже были только костюмы от Большевичка, ботинки Красная Заря и одеколон САША
А теперь давай трезво посмотрим на окружающий мир. Есть много замечательных проектов, которые ведет Redhat - spacewalk например. Или FDC. И где они в остальных дистрибутивах?> Этот зоопарк дает свободу выбора.
Скорей свободу не выбирать.
> Если все децентрализованая система более устойчивая.
Более устойчивая к чему? К каким угрозам? Что во всех попдистрах будут предсказуемые версии софта, который можно будет доводить до ума силами всего сообщества?
> Космонавт просто решил возглавить
Что возглавить? Это не русский нанотех, возглавив который можно попилить кучу бабла.
Если есть ответы по существу, буду рад послушать.
>> Космонавт просто решил возглавить
>Что возглавить?Процесс централизации и индустриализации разработки. Да только жиденькие у него позиции в силу каноникаловской специфики работы с апстримами, когда "точить некогда, пилить надо". За что и критикуем.
В таком случае надо менять систему версионности релизов как предлагал Торвальдс. Тоесть версия ПО должна привязываться не к функциональности а к дате. Тогда да, будет синхронизация =)
IMHO, есть более простая проблема - нет сервиса, который позволяет хотя бы просто строить пакеты под все дистрибутивы. Например, чтобы на том же лаунчпаде объединить мэйнтейнеров одного и того же пакета, но из различных дистрибутивов.
>IMHO, есть более простая проблема - нет сервиса, который позволяет хотя бы
>просто строить пакеты под все дистрибутивы. Например, чтобы на том же
>лаунчпаде объединить мэйнтейнеров одного и того же пакета, но из различных
>дистрибутивов.Вы когда-нибудь выглядывали за пределы линчпада? Там есть openSUSE Build Service, например. И этерсофтовский проект Tartarus.
Опенсусевский сервис неплох, но непонятно, каков механизм добавления новой платформы, если она нужна.
>Опенсусевский сервис неплох, но непонятно, каков механизм добавления новой платформы,
>если она нужна.Если нужна -- поинтересуйтесь. (сам не интересовался до сих пор)
Лично мне - не нужна. Я просто отметил, что затыки в социальной составляющей есть даже на уровне отстройки пакетов.
молодец!Gentoo на передовую, а Ubuntu & RHEL & Debian будут вместе пилить одни и теже версии... может даже договорятся о полу-автоматической пересылке патчей между дистрами.
Проще сделать единый пакетный формат.
В чем проблема? Оставить в каждом своё родное rpm, deb...но сделать ещё типа universal linux package .ulp?
Где-то видел подобное, только не помню где.
>Где-то видел подобное, только не помню где.Ммм... autopackage, zeroinstall, что-то-там-еще...
> Проще сделать единый пакетный формат.Этого мало. В разных дистрибах либы имеют разные версии и разложены по разным пакетам, так что при установке "чужого" или универсального пакета вылезут проблемы зависимостей.
Вот если бы договориться еще о составе основных библиотек, да научиться их делать так, чтобы новые версии были бинарно-совместимы с предыдущими... Одним словом, соорудить некий единый для всех дистров API - всем стало бы проще (разработчикам - особенно).
>> Проще сделать единый пакетный формат.Сделайте, коль проще. Вообще-то завернуть во что-то одно rpm и deb с их различиями в дизайне (например, установка rpm принципиально неинтерактивна, а установка deb предполагает необязательную, но возможную интерактивность) -- непросто.
>Вот если бы договориться еще о составе основных библиотек, да научиться их
>делать так, чтобы новые версии были бинарно-совместимы с предыдущими... Одним словом,
>соорудить некий единый для всех дистров API - всем стало бы
>проще (разработчикам - особенно).Почитайте про LSB, там и этим заморачиваются. Только параллельно стоит глянуть критику Ульриха Дреппера, её на них есть.
.tar.{bz2,gz,lzma}! Нет ничего универсальнее!
>.tar.{bz2,gz,lzma}! Нет ничего универсальнее!Ага, как в школе на уроках химии -- "из угля и воды". Получить, скажем, колбасу.
Новичкам сюда: http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/
Дайте людям удобный инструмент (лёгкий в освоении и использовании) для сборки из исходников в пакет. Я кстати такой Грааль нашёл для себя - abs в Archlinux
Учитывая заявление Шатлворта, можно сказать что к этому скоро прийдут. Заодно можно написать какой-нить Linux Installer Daemon, для простоты и кастомизации, и т.д. Только это будет воспринято в штыки красноглазиками ибо уже существует аналог в другой враждебной (для них) оси. А во-вторых, как уже говорили, для этого необходимо будет стандартизировать API/ABI, что в общем-то большой кусок работы и достаточно нереальный.
заопарк да и только с дистрибутивами конечно, если смотреть с точки зрения пользователя.а если смотреть с точки зрения "бывалого линуксойда" - то здоровая конкуренция.
а ведь мысль интересная, но не дальновидящая.
По хорошему, конечно должен быть порядок, но какой порядок - это уже дело эволюции свободного по и линукса.
Да, да! Давайте щас всех под Убунту сгоним и у Шатлврота разрешения спрашивать можно ли выпускать релиз того или сего...
Как всегда, чтобы дискредитировать идею, болтуны доводят её до абсурда.
Идея абсолютно глупая
>Как всегда, чтобы дискредитировать идею, болтуны доводят её до абсурда.Абсурдом скорее является идея. Примерно как и коммунизьм -- всё бы хорошо, да только пока не начинаем рассматривать реальных людей заместо идеальных. И прекращаем утыкаться головой в материализьм.
внутри-видовая борьба сильнее меж-видовой.
только так можно объяснить Ваш комментарий.мне, как человеку из сообщества, не привязанному к конкретному дистру, выгоднее, чтобы в любом дистрибутиве было стабильное, с последними возможностями и не дырявое по.
а ещё мне хотелось бы, чтобы в каждом дистре появлялись успешные наработки из других.
и чтобы банальные вещи (например, настройка сети) были более менее похожи, в идеале стандартны, и оптимальны.
чтобы дистростроители не цеплялись за свои костыли только потому, что они их костыли, а не "какого-то там космонафта из африки".
меня не устраивает формулеровка - наш дистр лучше потому, что мы его сертифицировали в фстэк.
>внутри-видовая борьба сильнее меж-видовой.
>только так можно объяснить Ваш комментарий.Виталий, повторюсь: я критикую как человек, который в этом варится.
>мне, как человеку из сообщества, не привязанному к конкретному дистру, выгоднее, чтобы
>в любом дистрибутиве было стабильное, с последними возможностями и не дырявое
>по.
>а ещё мне хотелось бы, чтобы в каждом дистре появлялись успешные наработки
>из других.
>и чтобы банальные вещи (например, настройка сети) были более менее похожи, в
>идеале стандартны, и оптимальны.
>чтобы дистростроители не цеплялись за свои костыли только потому, что они их
>костыли, а не "какого-то там космонафта из африки".Это означает продуктивную работу с апстримами и интеграцию дистрибутивных патчей.
А как раз Ubuntu и славится ныне как немеряным объёмом специфичных костылей на скору руку (по-человечески ж сделать быстро не получится, а костыли потом нормальный апстрим не принимает), так и хроническим неумением/нежеланием/whatever работать с апстримами.
Та же федора как проект им сто очков вперёд даёт именно по этой части.
Поймите, моя тут проблема _именно_ в том, что они пытаются на шару напрячь других и совсем не хотят сами играть так, как принято в этой песочнице (и не зря принято, поскольку работает). И то, что я причастен к разработке ALT Linux -- тут только тем боком, что я _вижу_ немножко эти всякие процессы.
Не люблю халявщиков, даже если они и сами халяву устраивают.
>меня не устраивает формулеровка - наш дистр лучше потому, что мы его
>сертифицировали в фстэк.А это из серии "годится для оракла" -- некоторым сильно важно, остальным по барабану.
ясно. я прочитал.
не согласен в корне. но и спорить дальше не хочу. мы говорим на разных языках. и о разных процессах.
Ваша задача - не допустить. моя - объединить.p.s.:
а вот это:
>>меня не устраивает формулеровка - наш дистр лучше потому, что мы его сертифицировали в фстэк.
>А это из серии "годится для оракла" -- некоторым сильно важно, остальным по барабану.никакого отношения к ораклу не имеет. сертификация фстэк - нужна госструктурам.
а для субд оракл нужна сертификация компании оракл. и только оракл.
короче - альтлинух не сертифицирован ораклом для их ПО.
>>А это из серии "годится для оракла" -- некоторым сильно важно, остальным по барабану.
>никакого отношения к ораклу не имеет. сертификация фстэк - нужна госструктурам.Знаю, просто обобщаю по сертификаци_ям_.
мне нравится идея. А то Сандербёрд в Федоре 10 до сих пор не обновили, хотя после выпуска новой версии прошло более месяца(!). И это только один пример.
>мне нравится идея. А то Сандербёрд в Федоре 10 до сих пор
>не обновили, хотя после выпуска новой версии прошло более месяца(!). И
>это только один пример.и, конечно, в этом виноваты авторы громоптицы, а не тормоза-майнтайнеры. всенепременно. и авторы громоптицы должны смотреть, чего там майнтайнер напортачил ии за ним поправлять. угу.
>и, конечно, в этом виноваты авторы громоптицы, а не тормоза-майнтайнеры. всенепременно. и
>авторы громоптицы должны смотреть, чего там майнтайнер напортачил ии за ним
>поправлять. угу.Предложение Шатлворта облегчает работу авторов и ментейнеров.
>Предложение Шатлворта облегчает работу авторов и ментейнеров.Агащаз. К понедельнику реквием-с.
а мне облегчает.
я ведь не только под альлинух пишу...
>а мне облегчает. я ведь не только под альлинух пишу...Не о том. "В альтлинухе" Вам не навязывают сроков. А тут именно что пытаются.
э нет. тут у меня один срок, а не для каждого дистра в отдельности.
и опять же не навязывают, а рекомендуют... мне "не впадлу" прислушаться к рекомендациям (если успею, смогу или будет желание)а иначе имеем что имеем - в разных дистрах разные версии по, но самое плохое - зависимости. мало того, что версии разные, так в каждом дистре ещё по разному называются и их разное количество.
вот тут кто-то уже приводил пример, что скайп для всех имеет один деб для всех деб-ориентированных дистров, а для рпм-ориентированных каждый свой.
почему? да потому что этот деб поставиться и будет работать, а например рпм для рх в 95% не будет работать на сузе. причина? в основном зависимости.и никто не ставит эти вопросы. что ж. если их ставит Марк - я поддерживаю
>э нет. тут у меня один срок, а не для каждого дистра в отдельности.Внимание, вопрос: интересы какого поставщика при этом учтены более всего? Как видим по пляскам вокруг xorg, они подчас конфликтуют.
>а иначе имеем что имеем - в разных дистрах разные версии по
Мало того, ещё и с разными патчсетами и дефолтными конфигами. И упакованные разными людьми. Есть из чего выбрать под свой вкус при его наличии. Ужас?
>но самое плохое - зависимости. мало того, что версии разные, так
>в каждом дистре ещё по разному называются и их разное количество.Этот вопрос вообще не имеет к тому отношения.
>вот тут кто-то уже приводил пример, что скайп для всех имеет один
>деб для всех деб-ориентированных дистров, а для рпм-ориентированных каждый свой.
>почему? да потому что этот деб поставиться и будет работатьПотому что "деб-ориентированных" целевых для этой софтины -- полторы штуки, растущих от Debian.
>а например рпм для рх в 95% не будет работать на сузе. причина?
>в основном зависимости.В основном существенно разное происхождение этих дистрибутивов. Они не являются "генетически близкими" родственниками, в чём есть и плюсы, и минусы.
>и никто не ставит эти вопросы. что ж. если их ставит Марк - я поддерживаю
Да ставят и работают. Просто он ещё и на эстраду выскакивает поплясать.
>>а например рпм для рх в 95% не будет работать на сузе. причина?
>>в основном зависимости.
>В основном существенно разное происхождение этих дистрибутивов. Они не являются "генетически близкими" родственниками, в чём есть и плюсы, и минусы.странный разговор пошёл.... так rpm как расшифровывается?
>>и никто не ставит эти вопросы. что ж. если их ставит Марк - я поддерживаю
>Да ставят и работают. Просто он ещё и на эстраду выскакивает поплясать.это вообще - no comment.
>странный разговор пошёл.... так rpm как расшифровывается?RPM Package Manager, и уже давно. См. http://rpm.org/
:-D манипулирование словами... словоблудие..
хорошо... изначально (как Вы выражаетесь - генетически) rpm назывался как?
и откуда пошёл?и ещё, c Вашей же ссылки:
>RPM is a core component of many Linux distributions, such as Red Hat Enterprise Linux, the Fedora Project, SUSE Linux Enterprise, openSUSE, CentOS, Mandriva Linux, and many others.так шта-а-а... тяните Вы все свои костыли (как ниже Вы написали о нелёгкой судьбе мэнтейнера) по своему собственному почину и в разные стороны... как лебедь, рак и щука.
задолбаешься под всех Вас код подстраивать. c дебом проще.
>:-D манипулирование словами... словоблудие..Виталий, не стоит заниматься именно что манипулированием словами. Я предпочитаю точные формулировки. При выборе между краткостью и точностью по возможности предпочитаю точность.
>хорошо... изначально (как Вы выражаетесь - генетически)
Я выразился в смысле пути происхождения дистрибутивов. Это _не_ то же, что "изначально". Вы смешали точку и отрезок, затем ещё и говорите, что это я так выражаюсь.
>rpm назывался как? и откуда пошёл?
Изначально rpm назывался rpm, а услышать Вы явно хотели "RedHat Package Manager, который пошёл из Red Hat Linux". А SuSE "изначально" называлась Slackware.
>и ещё, c Вашей же ссылки:
>>RPM is a core component of many Linux distributions, such as Red Hat Enterprise Linux,
>>the Fedora Project, SUSE Linux Enterprise, openSUSE, CentOS, Mandriva Linux,
>>and many others.
>так шта-а-а... тяните Вы все свои костыли (как ниже Вы написали о
>нелёгкой судьбе мэнтейнера) по своему собственному почину и в разные стороны...
>как лебедь, рак и щука.Это ещё один занимательный вопрос, но другой. Я бы его назвал rpm macro hell. :)
>задолбаешься под всех Вас код подстраивать. c дебом проще.
Нет, тут _код_ обычно подстраивать незачем. Подстраивать приходится _спек_, и то можно не выпендриваться и вместо оптимизации используемых макроконструкций с учётом выбора, доступного в конкретном дистрибутиве, использовать довольно тупые. Получится примерно так же многословно, как и в debian/rules, но будет действительно "проще".
PS: я ответил на Ваши вопросы или только добавил раздражения? Если последнее -- извините, не хотел.
>Виталий, не стоит заниматься именно что манипулированием словами. Я предпочитаю точные формулировки. При выборе между краткостью и точностью по возможности предпочитаю точность.отлично, альтлинух произошёл от мэндрека, а тот в свою очередь от красной шапки. это точная формулировка? родственные связи доказаны?
>Я выразился в смысле пути происхождения дистрибутивов. Это _не_ то же, что "изначально". Вы смешали точку и отрезок, затем ещё и говорите, что это я так выражаюсь.см. выше, а так же:
http://en.wikipedia.org/wiki/ALT_Linux и http://ru.wikipedia.org/wiki/MandrakeLinux
>Нет, тут _код_ обычно подстраивать незачем. Подстраивать приходится _спек_, и то можно не выпендриваться и вместо оптимизации используемых макроконструкций ....
>PS: я ответил на Ваши вопросы или только добавил раздражения? Если последнее -- извините, не хотел.извиняюсь конечно, но я и так прекарасно знаю положение дел. мне особо разъяснять не нужно. и одними макросами тут не отделаешься, если в проекте слишком много зависимостей и версий. особенно когда они взаимоисключающи с другим ПО (особенно системным).
>отлично, альтлинух произошёл от мэндрека, а тот в свою очередь от красной
>шапки. это точная формулировка? родственные связи доказаны?Это не совсем точная формулировка (макропакеты существенно отличаются на каждом шаге в каждый год из тех, когда уже заглядывал в спеки -- пусть с 2001), но родственные связи скорее таковы. У альта есть ещё некоторая примесь suse'шности в т.ч. по пакетной/патчевой базе и спекам, а также debian по инфраструктурным и организационным моментам, но от обсуждаемой части (пакетные менеджеры и пакеты) это уже дальше.
>>Я выразился в смысле пути происхождения дистрибутивов. Это _не_ то же, что
>>"изначально". Вы смешали точку и отрезок, затем ещё и говорите, что это я так
>>выражаюсь.
>см. выше, а так же:И тем не менее.
>и одними макросами тут не отделаешься, если в проекте слишком много зависимостей
>и версий. особенно когда они взаимоисключающи с другим ПО (особенно системным).Виталий, макросы и зависимости практически не пересекаются. Первое -- build time, второе -- install time.
>но от обсуждаемой части (пакетные менеджеры и пакеты) это уже дальше.Э нет! :-D
обсуждали как раз родсвенные связи (и только для примера я привёл rpm).
теперь то конечно, все рли-бэзед дистры, что родсвенники из ширли-мырли - "Тётя! так сколько нас было?!"
>Виталий, макросы и зависимости практически не пересекаются. Первое -- build time,второе -- install time.
до билд тайм надо ещё определить как в данном дистре называется пакет, сколько их, какая там версия и что туда бекпартировали/изменили ментейнеры.
пример? pppd - что ни дистр и версия, то новые траблы.
>>но от обсуждаемой части (пакетные менеджеры и пакеты) это уже дальше.
>Э нет! :-D
>обсуждали как раз родсвенные связи (и только для примера я привёл rpm).Это совсем высокоуровневое.
>>Виталий, макросы и зависимости практически не пересекаются. Первое -- build time,
>>второе -- install time.А это два _отдельных_ низкоуровневых вопроса, имеющих прямое отношение к тому высокоуровневому.
>до билд тайм надо ещё определить как в данном дистре называется пакет,
>сколько их, какая там версия и что туда бекпартировали/изменили ментейнеры.Для этого полезны сайты а-ля http://rpm.pbone.net, http://rpmfind.net, http://sisyphus.ru или вот http://packages.debian.org. При внятном и вытащенном из пакета ченжлоге там же можно получить общий ответ и на последний вопрос.
>пример? pppd - что ни дистр и версия, то новые траблы.
Вы только не обижайтесь, но это называется не "я разбираюсь", а "каша в голове" :(
build time конкретного пакета, пусть конкретного src.rpm -- это то, к чему имеет отношение конкретная макросистема. Сравните с версией стандарта debhelper и разными доступными наборами dh_*.
install time -- это экспортируемый список удовлетворяемых зависимостей, включая тривиальные файловые имена, name+soname библиотек и менее тривиальные виртуализованные компоненты, включая multiarch и модули расширения скриптовых языков.
вот я не верю, что один из мэнтейнеров в альте до сих пор не понял о чём я говорю...
вот скажите, для какого хрена придумана вот эта утиль (ABI Compliance Checker)?
http://www.linux.org.ru/view-message.jsp?msgid=3948420&lastm...
ps:
про кашу - не верю, что достаточно опытный мэнтейнер может абсолютно не понимать задач программиста, пытающегося оформить свой труд для разных дистров.
>вот я не верю, что один из мэнтейнеров в альте до сих
>пор не понял о чём я говорю...Вы просто в одну кучу мешаете _разные_ проблемы, ряд из которых действительно существует и решаем (порой даже решается, но не всегда).
>вот скажите, для какого хрена придумана вот эта утиль (ABI Compliance Checker)?
Ммм... это ИСП РАН, что ли? (простите, на LOR давно предпочитаю не ходить) Если да -- то после прослушивания двух или трёх докладов разработчиков у меня всё равно несколько смутное представление о том, для какого именно хрена она действительно придумана. Хотя это скорее в силу моих нестолкновений в лоб с их предметной областью.
>ps:
>про кашу - не верю, что достаточно опытный мэнтейнер может абсолютно не
>понимать задач программиста, пытающегося оформить свой труд для разных дистров.Может быть и так, если майнтейнер -- в первую очередь админ. Это как учёные и инженеры. :)
Не хотите привести какой-нить конкретный пример проблемы из тех, которые обобщали?
"В процессе разработки софтины X и упаковки её для дистрибутивов A, B и C повылазило следующее: ..."В качестве prior art могу предложить эту статью (и да, этот апстрим шесть лет назад был в курсе про ALT и Билли сам вышел на меня, по случаю тогда паковавшего tvtime в альте): http://freshmeat.net/articles/lessons-in-packaging-linux-app...
Это утилита для поиска проблем в бинарной совместимости разных версий разделяемых библиотек в Linux на языках Си/C++. Подробнее см. http://ispras.linux-foundation.org/index.php/ABI_compliance_...
Эта утилита пришла на смену давно известной icheck, http://www.digipedia.pl/man/icheck.1.html
дык и я о чём?
....апробирован между дистрибутивами Debian и Ubuntu. Если к этому процессу подключатся ДРУГИЕ, БОЛЕЕ МЕЛКИЕ дистрибутивы, это....Классно РедХат и СуСю подкололи!
Идея на самом деле здравая. О едином API, формате пакетов, синхронизации версий пакетов между разными дистрами и т.д. говорят уже достаточно давно. Но к сожалению, так ни к чему до сих пор и не пришли. А ведь из-за это тормозиться портирование огромного количества софта существующего например под виндовс или тот же Mac. Например, я бы с удовольствием поставил бы себе Lingvo или тот же Promt (да-да, и деньги заплатил бы. За нужный и хороший продукт почему бы и нет?). Однако разработчики на сайте Lingvo однозначно высказались по этому вопросу, что они не знают под какой дистр затачивать программу. Пилить "его под все дистрибутивы сразу, пусть даже под десяток самых популярных, неоправданная трата времени и ресурсов. Так что пока не будет либо единого стандарта API или формата бинарных пакетов или какого-то одного, явного, охватывающего хотя бы 40-50% рынка линукс-систем, дистрибутива - никто портированием заниматься не будет".
И это не единственный пример. Так программ огромное количество. Так буду надеяться, что может хоть у кого-то что-то выйдет в направлении стандартизации.
да гон это все. тот же vmware или дрова от nvidia ставятся из бинарного блоба на любой дистр, повторить сей результат не трудно. смысла (т.е. прибыли) они не видят в портировании, вот и все.
>Однако разработчики на сайте Lingvo однозначно высказались по этому вопросу,
>что они не знают под какой дистр затачивать программу. Пилить "его
>под все дистрибутивы сразу, пусть даже под десяток самых популярных, неоправданная
>трата времени и ресурсов. Так что пока не будет либо единого
>стандарта API или формата бинарных пакетов или какого-то одного, явного, охватывающего
>хотя бы 40-50% рынка линукс-систем, дистрибутива - никто портированием заниматься не
>будет".Им к Etersoft, у которых есть инфраструктура для сборки под массу фрюниксов. Если интересно, передайте.
>инфраструктура для сборки под массукак-то оно нехорошо звучит
кому от этого многообразия легче?
непонятно
>>инфраструктура для сборки под массу
>как-то оно нехорошо звучитЕсли вырвать, звучит ещё хуже. Из контекста.
>кому от этого многообразия легче? непонятно
Видите ли, стандартизация разная бывает. "Вы можете выбрать любой цвет Форда при условии, что это чёрный" или обувь стандартного размера меня лично не устраивает.
Бывают "хорошие" различные вещи (когда различия продиктованы резонными причинами), "вынужденные" (когда навязаны объективными внешними факторами) и "плохие" (когда по своему произволу устраивают разнобой на ровном месте).
Вот то что уже Марк обратился с данным предложением к общественности по сути уже является первым шагом к единой пакетной системе API. Да, будущее будет за единым стандартом и это никак не будет мешать конкуренции, а только усилит её, и программных пакетов появится масса, как грибы после дождя.
Это всё отмазки ленивых вендузятников.
http://www.skype.com/intl/en/download/skype/linux/
Внимание, вопрос: для скольких линуксов оно здесь заточено?* Software requirements
* Qt 4.2.1+
* D-Bus 1.0.0
* libasound2 1.0.12
Пройдём по ссылке http://www.skype.com/intl/en/download/skype/linux/choose/
Что мы видим? Вроде как имеются дистрибутивы для 7 или 8 дистрибутивов. А копнём глубже...
и оказывается, что там предлагают скачать: skype-debian_2.0.0.72-1_i386.deb либо skype-2.0.0.72-fc5.i586.rpm либо skype-2.0.0.72-suse.i586.rpm либо skype-2.0.0.72-mdv.i586.rpm либо skype-2.0.0.72-centos.i586.rpm, ну и некий skype_static-2.0.0.72.tar.bz2.
Во-первых, интересно то, что для Ubuntu, Debian и Xandros отдаётся один и тот же файл, а для rpm-based - каждому свой.
Во-вторых, интересно наличие tar.bz2, который, как ясно при ближайшем рассмотрении, работает вообще в любом линуксе ветки 2.6 или может даже древнее.
>такое положение дел затрудняет контроль над сообществомfixed
Поиск и исправление ошибок при тестировании различных версий кода наоборот куда проще. Вообще ошибку куда проще найти глядя на проблему с разных сторон.
близится осень, у шатлврота опять обострение начинается…скажите же ему уже кто-нибудь, что его бубунта — не единственный и не самый лучший дистриб, а?
Не вполне понятно, о чем столь горячая дискуссия? По сути предложение (предпочту отделить личность предлагающего от мысли) сводится к тому, чтобы каждый апстрим-проект в каждый момент времени имел 2 версии тгз-шника: стейбл, в которой только фиксятся баги, и девел, в которую добавляется новая функциональность. При переходе количества в качество девел морозится в стейбл и открывается новый девел.
Многие проекты так и делают.
Дальше бери чего хочешь.А насчет всего остального еще Макконел говорил: "одни параметры качества зачастую конфликтуют с другими". Все зависит от того, что нужно. Вон скайпы собрали статически пакетик, ставь его в любой линух и не парься (тут тебе и API универсальный, вернее в данном случае ABI). Ну и что, что 20 Мб. Место на дисках дешевеет быстро.
>"Хуже всего, то что в одно и то же время разные дистрибутивы могут включать совершенно разные версии вашего кода. Такое положение дел затрудняет поиск и исправление багов, и из-за этого трудно определиться, на какой версии нужно сконцентрироваться, чтобы довести ее до стабильного состояния"Ну и бред.
Обычно разработчики концентрируются на последней версии.
Мантейнеры -- на той, которую они готовят для включения в релиз и обновления предыдущей версии.
Служба поддержки клиентов -- на той, что установлена у клиентов.
ВСЁ!Космонавт, ты не прав.
>Космонавт, ты не правсперва добейся (с)
>Обычно разработчики концентрируются на последней версии.
ведь предлагается, блин, идея привести разработку в порядок.
чтобы последняя версия всегда становилась стабильной и становилась вовремя.
дорога ложка к обеду.>Мантейнеры -- на той, которую они готовят для включения в релиз
мантейнерам будет проще
>Служба поддержки клиентов -- на той, что установлена у клиентов
и службе поддержки в результате тоже
iZEN, извени, но ты задолбал со своим проприетаризмом. ну нет у меня поддержки от "службы поддержки клиентов"! нет!
это первое.
второе - понятие стайбл у разных ментейнеров разное. в том числе и в зависимости от целевой аудитории и направленности конкретного дистрибутива.
а зависимости от других, сторонних, пакетов и их версий?!!
ну и третье - развитие и многообрацие различных решений на базе linux настолько больше, чем у остальных свободных и "свободных" (вместе взятых кстати) *nix, что подходы, характерные для последних, не применимы для линуха вообще и для всего сообщества в частности.
тем более смешно слушать рекомендации по оптимизации от этого меньшинства.
соответсвенно, любые попытки консолидации сообщества нужно только приветсвовать.
чтобы не было как у басни Крылова - лебедь, рак и щука.... хотя... может это и есть лично Ваша цель?
Нет, не любые.Не всем, видите ли, падается в обморок от щастья гнуть горб на отдельно взятого дядю по его плану и под его барабан. И не всем вообще ходится стройными колоннами, вообще-то есть ещё такие вещи, как работа и семья -- и они важнее календариков у этих дядь.
Мы-то здесь вроде по большей части знаем, что это такое, и всё равно не доходит.
Текущая схема _при условии работы с апстримами_ вполне адекватна и масштабируема, просто некоторым гигантским дятлам стоило бы перестать задалбывать всех слонов в округе и наконец заняться тем, чтоб свои _оплачиваемые_ разработчики начали тратить время на отправку и интеграцию патчей в апстрим. В том числе к старым стабильным (но поддерживаемым) веткам. А не нести пургу вида "ну почему вы все не как я, а ну давайте стройтесь".
Бо как-то интересно выходит -- всю инфраструктуру молча тащит редхат (ядро, gcc, иксы, PS: glibc тоже), а этот новый Балмер будет тут подкатываться и уплясывать всех как угодно.
>И не всем вообще ходится стройными колоннами, вообще-то есть ещё такие вещи, как работа и семья -- и они важнее календариков у заставляеЮточно. вот со "школьным" линухом как тут быть - не понятно.
даёшь в каждую школу свой дистриб!для Вас линух - работа.
Вы - наёмный работник.а сообщество на то и сообщество, чтобы договариваться, жить общими интересами и т.д.
Вы чего боитесь? что "космонафт" будет....????
а что он будет?
будить Вас по ночам и заставлять на него работать?
>точно. вот со "школьным" линухом как тут быть - не понятно.
>даёшь в каждую школу свой дистриб!
>для Вас линух - работа.
>Вы - наёмный работник.Вы часом не с дуба рухнули? Я в школьном проекте участвую именно как человек из сообщества. И здесь в том же качестве высказываюсь. А зряплату получаю на совсем другой работе, хотя и связанной непосредственно с линуксами (в том числе ALT). При этом сказать, что "наёмный работник", довольно сложно -- фактически я собрал всех ключевых людей в этом уникальном по стране коллективе. Сидим мы в Киеве, чтоб не было недоразумений.
Для меня работа -- это в первую очередь люди. И в отношении к людям -- не работа главное.
>а что он будет? будить Вас по ночам и заставлять на него работать?
Я ему уже что хотел -- то давно сказал в sounder@.
Собсно вольному воля, радуетесь предложенному -- идите спросите, как теперь будете вместе реализовывать.
ну так сколько дистрибутивов в школьном проекте?
>ну так сколько дистрибутивов в школьном проекте?Четыре.
ясно :-Dальт за опенсоурс в школах... если этот опенсоурс от альта.
>ясно :-D альт за опенсоурс в школах... если этот опенсоурс от альта.Во-первых, я не говорю за них (не будучи даже сотрудником); во-вторых, Вы сделали очередной неверный вывод.
Не полезу сейчас к AEN в блог за точными формулировками, но смысл был такой, что и к работе над техусловиями приглашались все желающие, и в работе над проектом он лично был рад видеть всех, кто согласен работать над одним репозиторием, а не бегать с клонами. Может, ещё что-то, не помню уж.
Похоже, Michael Shigorin "несколько" задет высказываниями близкого по роду деятельности человека? ;-) Я не разработчик, но, посмотрев на поведение того или иного субъекта/объекта, могу примерно предположить, чего же он хочет. Будь то Шаттлворт, Микрософт или парни из Дебиан. Кстати, последние представляются мне довольно суровыми людьми, замечательно делающими свою работу и не отвлекающимися на самолюбование.
По сабжу: да, на мой взгляд - пытается возглавить. Получится или нет - сказать не могу, но надеюсь, что нет. Наверно потому, что мне не хотелось бы повального распространения *никсов на десктопы. Пусть будет множество систем... Тогда каждый найдет себе то, что ему по душе - и перестанет уделять столько много времени тому, что является лишь инструментом.
>Похоже, Michael Shigorin "несколько" задет высказываниями близкого по роду деятельности человека? ;-)
>Я не разработчик, но, посмотрев на поведение того или иного субъекта/объекта,
>могу примерно предположить, чего же он хочет. Будь то Шаттлворт, Микрософт
>или парни из Дебиан. Кстати, последние представляются мне довольно суровыми людьми,
>замечательно делающими свою работу и не отвлекающимися на самолюбование.Эти-то? :) Да чего стоит собрать исходники под Linux под Linux и оформить DEB-пакетом при налаженной схеме портирования? Ровным счётом НИЧЕГО! Сам автор иходников УЖЕ сделал половину работы.
Мантейнеры левой задней ногой в свободное от основной работы время делают портирование в Debian/Ubuntu. Если собранный и установленный пакет валит операционную среду, то отправляют подробнейший багрепорт автору вместе со своими комментариями (типа специалисты).Другое дело -- портирование ПО, написанного на Linux и под Linux, на FreeBSD. Вот тут задачи решаются: вычищение linux-зависимостей из исходников (написание патчей), приведение в порядок путей установки (в Makefile порта) и интеграционное тестирование собранного пакета.
>Эти-то? :) Да чего стоит собрать исходники под Linux под Linux и
>оформить DEB-пакетом при налаженной схеме портирования? Ровным счётом НИЧЕГО!Слова не мужа, но мальчика. Сами-то пробовали или Рабинович напел?
>Сам автор иходников УЖЕ сделал половину работы.
Два балла по математике и логике. Если автор (или группа таковых) и сделал пусть половину -- ещё половина осталась.
>Мантейнеры левой задней ногой в свободное от основной работы время делают портирование
>в Debian/Ubuntu. Если собранный и установленный пакет валит операционную среду, то
>отправляют подробнейший багрепорт автору вместе со своими комментариями (типа
>специалисты).Кажется, в таких случаях принято предлагать не курить это больше.
>Другое дело -- портирование ПО, написанного на Linux и под Linux, на
>FreeBSD. Вот тут задачи решаются:ССЗБ. Гнули пальтсы, что самые крутые -- вот и пусть выгребают своё аутсайдерство. Это нормально.
PS: просто чтоб не быть голословным: http://sisyphus.ru/packager/mike/srpms
>>Эти-то? :) Да чего стоит собрать исходники под Linux под Linux и
>>оформить DEB-пакетом при налаженной схеме портирования? Ровным счётом НИЧЕГО!
>
>Слова не мужа, но мальчика. Сами-то пробовали или Рабинович напел?Инсталлировать — легко.
# cd /path/to/source
# ./configure
# make install prefix=/opt
Для создания DEB-пакета:
# checkinstall -D:))
>
>>Сам автор иходников УЖЕ сделал половину работы.
>
>Два балла по математике и логике. Если автор (или группа таковых)
>и сделал пусть половину -- ещё половина осталась.Что вы всё время оценки ставите? Школьным учителем работаете? Тогда понятно -- остаточный принцип финансирования на протяжении двух десятилетий оставляет следы.
>
>>Мантейнеры левой задней ногой в свободное от основной работы время делают портирование
>>в Debian/Ubuntu. Если собранный и установленный пакет валит операционную среду, то
>>отправляют подробнейший багрепорт автору вместе со своими комментариями (типа
>>специалисты).
>
>Кажется, в таких случаях принято предлагать не курить это больше.Ах да, мантейнеры выполняют одну очень важную миссию -- проводят ИНТЕГРАЦИОННЫЕ_ТЕСТЫ, чего не может позволить себе разработчик по причине отсутствия у него определённого дистрибутива с определённым окружением, как в дистрибутиве.
>>Другое дело -- портирование ПО, написанного на Linux и под Linux, на
>>FreeBSD. Вот тут задачи решаются:
>
>ССЗБ. Гнули пальтсы, что самые крутые -- вот и пусть выгребают
>своё аутсайдерство. Это нормально.А нету никакого аутсайдерства уже давно. Количество ПО для FreeBSD зшкаливает численность "пакетов" в любом из дистрибутивов Linux, возможно, исключая сильно гранулированный список Debian, в котором авторское ПО представлено не одним, а несколькими пакетиками.
"В списке Коллекции Портов FreeBSD на данный момент присутствуют 20551 портированных на FreeBSD программ."
http://www.freebsd.org/ru/ports/index.html
>Для создания DEB-пакета: checkinstall -DИнтересно, что бы Вы сказали об автогенерированном порте (если не говорить об импорте из чего-то уже неплохо структурированного навроде CPAN). Наверное, примерно то же, что и о синтетической еде.
>>Два балла
>Что вы всё время оценки ставите? Школьным учителем работаете? Тогда понятно --
>остаточный принцип финансирования на протяжении двух десятилетий оставляет следы.У меня есть квалификация (и опыт) преподавателя, но денег тем не зарабатывал: веду порой факультативы. На самом деле такие оценки ещё имеют подтекст "назад в школу", только не обижайтесь. :)
>>>Мантейнеры левой задней ногой в свободное от основной работы время
>>Кажется, в таких случаях принято предлагать не курить это больше.
>Ах да, мантейнеры выполняют одну очень важную миссию -- проводят ИНТЕГРАЦИОННЫЕ_ТЕСТЫ,
>чего не может позволить себе разработчик по причине отсутствия у него определённого
>дистрибутива с определённым окружением, как в дистрибутиве.Некоторые занимаются и тем (только оперировать обычно имеет смысл ещё и над репозиторием). Кто вычиткой, кто созданием этих самых тестов. Например, дебиановского lintian или альтовских qa-robot и repocop.
Но подразумевал в первую очередь то, что очерченный характер работы майнтейнеров является одним очень частным случаем, и то в существенной мере подлежащим автоматизации (как у нас вон Виталик Липатов и делает при помощи etersoft-build-utils имени себя).
>>>Другое дело -- портирование ПО, написанного на Linux и под Linux, на
>>>FreeBSD. Вот тут задачи решаются:
>>ССЗБ. Гнули пальтсы, что самые крутые -- вот и пусть выгребают
>>своё аутсайдерство. Это нормально.
>А нету никакого аутсайдерства уже давно.Ой, не смешите. Тут недавно гномятники пытались расшевелить солярщиков и бздишников, которые сидят и ноют, что-де "развитие linux only". А что делать, если та же десктопная инфраструктура разрабатывается именно там?
>Количество ПО для FreeBSD зшкаливает численность "пакетов" в любом из дистрибутивов
>Linux, возможно, исключая сильно гранулированный список Debian
>в котором авторское ПО представлено не одним, а несколькими пакетиками.И включая стопки тем для roundcube, справедливости ради.
Сравнивайте исходные пакеты, не придётся ссылаться на "гранулировку". См., например, http://blogs.koolwal.net/2008/12/19/counting-number-of-packa.../ (по моим подсчётам на скору руку, в pool сейчас чуть меньше 16000 исходных пакетов, не считая версий).
>"В списке Коллекции Портов FreeBSD на данный момент присутствуют 20551 портированных на
>FreeBSD программ."У freshports несколько другие данные, хорошо бы договорились уже, что ли.
Всё равно в любой нормальной куче софта львиная доля одному и тому же человеку никогда не понадобится и вопрос в том, есть ли всё нужное, а уже _потом_ -- какой процент угловых случаев приводит к необходимости что-то собирать самому в среднем по населению.
Лично у меня крайне редко возникает необходимость что-либо добавить к альтовским 9000+ пакетам (опять же в терминах исходных).
>Похоже, Michael Shigorin "несколько" задет высказываниями
>близкого по роду деятельности человека? ;-)Ну я-то с ним рядом не стоял, конечно, по масштабам. Общего разве что занятие дистрибутивами свободного софта, сообществами около них да вот apache майнтейнили -- он в дебиане, я в альте :)
Задевают не сами высказывания, а суть предложений и неафишируемый эгоцентризм.
>Ну я-то с ним рядом не стоял, конечно, по масштабамТак уж получается всю дорогу, что у нас в стране денежные затраты на подавляющее большинство работ всегда несоизмеримо меньше, чем на западе. И это с аналогичными параметрами продукции на выходе... Не буду занудничать по данному вопросу - он уходит в корни народности - а просто выскажу предположение. Может, в подобных случаях не последнюю роль играет как раз заносчивость, в какой-то степени наглость и тот самый пиар, которому западники научились на "отлично"? Поэтому, всем отечественным производителям (не важно чего) я могу пожелать лишь одного: смелее!
Его предложение конечно очень приятно звучит для тех, кого принято называть "конечными пользователями", но имеет ряд недостатков ИМХО.Во-первых, и это главное, в реальной жизни это очень трудно реализовать, потому что все дистрибутивы очень поразному понимают стабильность, разные степени важности у стабильности и нововведений. Потом ведь во многих дистрах (я думаю что в большинстве) ментейнеры делают работу для себя самих, т.е. им что-то нужно, они это делают и деляться сделанным с остальными. Если ментейнеру нужна именно эта фича, которую сломали в новой версии (а такое часто бывает, увы), то он дождется возвращения фичи перед добавлением новой версии в репы, даже если эта фича всем остальным не нужна или плюсы новой версии для остальных перевешывают отсутствие этой фичи. И вот в этот достаточно обычный рабочий момент система предложенная Шатлвортом ломается :-(
Во-вторых, а кто будет указывать на какой стабильной версии сконцентрироваться? Ментейнеры люди свободолюбивые и, зачастую, упрямые))
это не недостатки, а сложности
>Во-вторых, а кто будет указывать на какой стабильной версии сконцентрироваться? Ментейнеры люди свободолюбивые и, зачастую, упрямые))Выпуск и поддержку софта должны осуществлять вендоры, а задача дистрибутива дать все необходимые инструменты для инсталяции и возможности обновления софта. Тогда и все проблемы исчезнут.
>Тогда и все проблемы исчезнут.Так вот ты какая, серебряная пуля...
а я вот знал в варианте про северного оленя.....
Такое ощущение, что или перевод кривой, или этот космонавт сам не знает что мелет. Если в моём дистре есть программа, она априори УСТАРЕЛА. Если она мне позарез нужна, я полезу на сайт автора и поставлю свежую версию. ЭТУ ЖЕ свежую версию я буду исправлять на предмет багов. Что за бред "из-за этого трудно определиться, на какой версии нужно сконцентрироваться"?А вообще, беда Линукса вовсе не в наборе программ, а их тупой версионности и не менее тупой зависимости (плюнул в редхат). По идее, пакет должен запрашивать только минимально допустимую версию зависимых пакетов (типа ">= 1.2.*") - да и то не "свежести" ради, а только в случае появления нового API. Если я правильно ошибаюсь, GoboLinux так и делает.
К слову о стабильности... Что это такое и когда хоть раз она была в Линуксе? Очевидно же, что ЛЮБАЯ прога - априори "вечная бетта". Она может быть разной степени сырости, но ни о какой "стабильности" речи нет. Особенно в свете зависимости от других библиотек (которые в свою очередь снова понижают стабильность). А выкладывать "как бы работает, но я ещё не проверял" код - вообще моветон.
>Очевидно же, что ЛЮБАЯ прога - априори "вечная бетта".ещё раз уточню - в линуксе
>>Очевидно же, что ЛЮБАЯ прога - априори "вечная бетта".
>
>ещё раз уточню - в линуксеЯ вам открою глаза: ВЕЗДЕ.
>Я вам открою глаза: ВЕЗДЕ.фрисофт выел ваш мозг. существуют процессы, для которых необходимо ПО с надежностью в несколько девяток до и после запятой.
>>Я вам открою глаза: ВЕЗДЕ.
>
>существуют процессы, для которых необходимо ПО с надежностью
>в несколько девяток до и после запятой.Согласен. Но это ПО настолько убого, что жизни в нём нет.
>>>Очевидно же, что ЛЮБАЯ прога - априори "вечная бетта".
>>ещё раз уточню - в линуксеНет.
>Я вам открою глаза: ВЕЗДЕ.
Увы.
боюсь показаться предсказуемым.Photoshop CS3, Expression Studio 2, Skype 4.1 - самые обычные приложения, используемые ежедневно. Возможно, что вами также.
Серьёзных багов пока не обнаружено, достаточная функциональность.
>Photoshop CS3, Expression Studio 2, Skype 4.1 - самые обычные приложения, используемые
>ежедневно. Возможно, что вами также.Ни одним из этих не пользуюсь, об одном и не слышал.
>Серьёзных багов пока не обнаружено, достаточная функциональность.
На буке, с которого пишу, в данный момент установлено 2340 пакетов из нестабильной разработческой ветки ALT Linux. Используется, скорее всего, около половины -- давно не проходился с веничком.
Мной в bugzilla.altlinux.org повешено 39 [PS: открытых в данный момент] багрепортов серьёзности "normal" и выше (исключая minor и enhancement) и слежу ещё примерно за тремя сотнями открытых в данный момент (включая серверные и иные из не относящихся к этой машинке).
Сколь-нибудь заметная проблема наблюдается только одна -- давняя регрессия производительности в 2D драйвера radeon на RV250.
По серьёзности я склонен её характеризовать как normal.
Проблемы Microsoft Windows XP из списка "цепляет вирусы", "бутается об каждый чих" и "заваливает уведомлениями" я склонен характеризовать как major..critical.
Боюсь, по крайней мере объём этого ответа был предсказуем :(
>Проблемы Microsoft Windows XP из списка "цепляет вирусы", "бутается об каждый чих"
>и "заваливает уведомлениями"фразу от вас расцениваю как шутку
>>Проблемы Microsoft Windows XP из списка "цепляет вирусы", "бутается об каждый чих"
>>и "заваливает уведомлениями"
>фразу от вас расцениваю как шуткуТам был бы смайлик.
К сожалению, не так давно пришлось столкнуться с XP -- может, и приемлемая бы система (после прикручивания стопки софта, который на линуксе у меня из коробки), но даже этих трёх проблем достаточно, чтоб по возможности отложить следующее столкновение.
В итоге подумываю -- может, и этим людям проще линукс дать. По крайней мере livecd понравился.