Вышел Gentoo 2005.0

Понятно. :) Оказывается просто лень. ;) а не в раздувание дело.

> очему бы не выкладывать заодно с ebuild'ами и сырцами ещё рядышком и бинарные сборки, согласно определённой policy?

обилие платформ, зачем наступать на грабли дебияна(я выше уже отмечал про метадистрибуции) ? это кстати и ответ на вопрос "почему портэжи не на си(++)"

>почему бы не выкладывать заодно с ebuild'ами и сырцами ещё рядышком и бинарные сборки, согласно определённой policy?

Фишка в чём: если я ставлю 90% пакетов из бинарников, не тратя процессорное время и доверяя "сотрудникам по репозитарию", которые, в сыою очередь, следуют policy, которая меня в основном устраивает, я могу больше времени потратить на сборку и тестирование тех 0.1% пакетов, для которых я делаю ebuild. Не находите?

>Т.е. настолько приспособлены, что можно всё по cron'у?

На десктопе у меня так и сделано. Каждую ночь - emerge sync && emerge -u world

На серверах - emerge sync автоматом, emerge -u - по 5 минут в день на обзор обновлений.

саржа, ну я в прошлой жизни еще мандрейка ждал;), а теперь даже ебильдов не жду, просто переименновываю номер версии, сохраняя в оверлей и обновляю

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

Если у тебя в RPM-based стоит одна либа, на которую завязана вся ось, а ты собираешься поставить RPM, для которой нужна другая либа... Всё, приехали, RPM-hell. А в Gentoo для такого случая есть слоты.

2anonymous:

>потому что особенность в Gentoo как раз заключается в том чтобы собирать под себя

А особенность Unix-way заключается в том, чтобы делать "под себя" только то, что именно необходимо делать "под себя", а не "собирать один и тот же велосипед по себя"! Может лучше пусть каждый сделает частичку полезного, а не тратит процессорное время "только для себя"? Ведь пользователей дженту десятки-сотни тысяч? как вы думаете, какое количество ОБДУМАННЫХ и БЕСКОМПРОМИСНЫХ наборов флагов в USE у них?

нет, тут есть тонкость, которая слабо понятна адептам другой религии;)), так же как виндузятники многие не понимают, зачем им куда-то переходить, пока винда не летит). Заключается она в том что следить за процессом обновления не надо т. е. -> ставим большой найс и занимаемся своей работой, услышав свист об окончании установки/обновления запускаем или перезапускаем приложение

2Syncro:

>обилие платформ, зачем наступать на грабли дебияна(я выше уже отмечал про метадистрибуции)

Давайте не лукавить, а?:) 99% - x86 -можно начать с этого?

>это кстати и ответ на вопрос "почему портэжи не на си(++)"

а где ответ "Почему Python" и "Где pyshell системный и полнофункциональный"?

А почему я должен ставить рпм не из своего дистрибутива? Почему я не могу собрать либу сам?

2Syncro:

>нет, тут есть тонкость...

Про "тонкость" - это ты юзерам рассказывай:) Я Предложи конкретную вещь - ты сделал вид, что не понял:) Я предложил не повторять одни и те же действия тысячам пользователям дженту.

Ок, я скажу о том, о чём вы умолчали: поддерживать бинарный репозитарий, скажем так, "несколько сложней", чем сырцовый:), тут нужна координация и организация минимальная:)

> 99% - x86 -можно начать с этого?

так можно закончить Wintel'ом;)) дистрибутив только для х86 просто с другим окружением был бы велосипедом не так ли) ?

> а где ответ "Почему Python" и "Где pyshell системный и полнофункциональный"?

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

2anonymous:

>А почему я должен ставить рпм не из своего дистрибутива? Почему я не могу собрать либу сам?

Ага, а где же ты ebuild... т.е. spec возьмёшь для своего дистра???

Шучу, странно, но, к сожалению, джентушники, умеющие запускать emerge и "править" USE, и слакварщики, умеющие ./configure && make && make install, считают, что пользователи RPM-based дистров умеют только linuxconf'ом пользоваться (кстати, что это такое?:))

в Unix-либах для этого есть .so.x.x.x. Не знал:)))

> поддерживать бинарный репозитарий, скажем так, "несколько сложней", чем сырцовый:)

ну зачем еще один формат пакетов под кучи платформ и версий glibc, когда один сервер полностью способен обеспечить потребность сети в обновлениях, собирая из сорцов ?

Да просто действительно смешно когда говорят, что поставив рпм базэд систему я не могу что то собирать. Просто я не собираюсь делать мартышкин труд в большинстве пакетов. Но это не означает что я как мартышка сижу и не знаю как набрать ./configure --help

linuxconf давно deprecated и не думаю что все пользователи любых дистров о нем знают;)

2Syncro:

>потому, что так решил создатель)

Не ответ:) Создатель вне критики? Это мы уже проходили:)

>Я предубеждений против питона не имею

Я тоже не имею, но есть принципы Оккама, поэтому либо делаем python -shell (т.е. дорабатываем интерактивную его часть и переписывает init-скрипты на нём, либо реализуем emerge на bash+sed+awk - и то и друго вполне реально и несложно реализуемо. Хотя я больше склоняюсь ко второму - всё-таки попроще жить дальше будет)

2Syncro:

>ну зачем еще один формат пакетов под кучи платформ и версий glibc

Так бинарный формат по дженту вроде бы есть...

Не нужно новых форматов, по мне, так и rpm-формат избыточен... есть tar, cpio, если в репозитарии будут лежать i586.cpio.bz2 или i586.tar.bz2 с приложенным внутри списком зависимотей - этого будет вполне достаточно... Что мешает рядом положить ppc.cpio.bz2? Ведь, я надеюсь ebuild'ы проверяются хотя бы "на собираемость" на поддерживаемых платформах?

Я не хочу не кого злить и не считаю свое мнение правильным. Переезд на другой дистрибут для меня являеться большим потрясением. Другие конфиги. Все другое. Но я считаю - просто не обходимо смотреть что происходит с другими дистрибутами. Когда то давно я переехал с форточек на шапку, а потом на сусе. Сейчас не жалею. Переезд был вызван не возможностью пользоваться чем то. Сейчас уже не помню. Я думаю просто поставил Suse 5.3 и у меня все завелось. Пробывал наверно все популярные дистибуты. Сейчас на серверах использую Suse, но на ноутбуке и на тестовом сервере пользуюсь Gentoo. Тестовый сервер пересобирает "обноленные" пакеты для 3 комлектов конфигураций. Занят он этим около часа в день. Еще хронит локальную копию portage. В офисе выполняет функцию принт сервера(выбросить было жалко). На пробу ставил генто с моего дерева пакетов. Занимает минут 20-30 до рабочего состояния. Есть не приятности utf8, но я думаю это решаемо. Разобраться времяни нет. Завтра возможно начну ставить сервера на Gentoo. Правда конфигурацию для сусе еще лет 5(среднее время жизни сервера) надо будет хранить. Так что на сервере работает Suse пока сама не слетит или я не найду что нибудь лучше.

>Но это не означает что я как мартышка сижу и не знаю как набрать ./configure --help

А вот на Gentoo как раз знать как это набрать - не обязательно :)

Так и в рпм базед это не обязательно. ;)

> Не ответ:) Создатель вне критики?

да почемуже, только на вопросы выбора ответ известный: "исходный код открыт и свободен", потребности в дополнительной интерактивности я не разу не испытал, наоборот автоматика рулит:))

> либо реализуем emerge на bash+sed+awk

а классы то куда денете)) ?

А ещё у emerge есть маааааленькое, редко замечаемое, но всё же неприятное свойство, а именно python 2.0/2.2/2.3/2.4/etc. :(

А у rpm, при всех его недостатках, маааааленкое, редко замечаемое, но всё же полезное свойство, а именно его rpm-static вариаент практически во всех дистрах:)

2Syncro:

>потребности в дополнительной интерактивности я не разу не испытал, наоборот автоматика рулит:))

т.е. python как интерактивный shell тебя вполне устраивает?

>а классы то куда денете)) ?

Шутить изволите? Наверное туда же, куда и OpenGL в WinNT-Server - зачем зенитная противоракетная установка для борьбы с воробьями?:)

а еще у emerge есть возможность любого скольугодно сложного вмешательства в процесс установки (это про бэш и интерактивность) и функция постустановочной конфигурации(только вот последнюю почемуто не используют, нужна ли она вообще?), а еще возомжность установки этих самых вездеработающих статичных эрпээмок;))

> зачем зенитная противоракетная установка для борьбы с воробьями?:)

тогда смотрим внимательней на ебильды состоящие из 5-10 строк с метаинфой, урлом и например inherit kde. Классы позволяют как раз не изобретать велосипеды, а просто пользоваться уже созданным изменяя его в потомках

>а еще у emerge есть возможность любого скольугодно сложного вмешательства в процесс установки

Знаем...:) Хотелось бы меньше сущностей: или bash, или python

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

Знаем...:) не используют, потому как ИМХО неудобно... *.rpmsave/*.rpmnew + diff + "любой текстовый редактор" немножко удобнее - хотя тоже не идеал...

>а еще возомжность установки этих самых вездеработающих статичных эрпээмок;))

для этого их сначала найти нужно или изготовить:) Наскидку - попадались только opera-qtstatic...

>тогда смотрим внимательней на ебильды состоящие из 5-10 строк с метаинфой, урлом и например inherit kde

"Это хорошо, это 5":)

Параллельно смотрим на spec'и и смотрим, что же в них лишнего???:)

2Syncro:

>тогда смотрим внимательней на ебильды состоящие из 5-10 строк с метаинфой, урлом и например inherit kde

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

>Да как там с зависимостями в ebuild'ах за последние год-полтора?

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

> Знаем...:) Хотелось бы меньше сущностей: или bash, или python

какие-то уже капризы пошли, а не wishes, мир то не вокруг вашего пупа вертится и даже та его часть, что использует gentoo;))

> Наскидку - попадались только opera-qtstatic...

ну у меня ls *rpm на дистфайлах поболе выдал, хотя конечно не в масштабах общего количества пакетов ...

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

2Syncro:

>какие-то уже капризы пошли

Это не капризы, это Оккам придумал, вернее "сформализовал", а все хочет минимум энтропии (в т.ч. и в начных исследованиях, и софт-разработке) пользуются этими приципами, если не хотят погрязнуть в куче сущностей.

2Syncro:

>зависимости как обязательные так и опциональные сколько помню всегда были

Были, есть, или "как помнишь"? Особенно при удалении пакетов?

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

В rpm мне тоже не всё с зависимостями нравится, но там на счёт "нежёстких" зависимотей, по поводу удаления/целостности системы там более-менее всё в порядке.

по-моему зависимости при удаление все еще не обслуживаются, хотя есть средство узнать кто зависит от этого пакета перед удаление.

Итог (как для меня), чего не хватает для gentoo:

1) Нежелание разработчиков изучения и понимания базовых Unix-утилит и как следствие - лишний python при возможности реализовать то же самое без него.

2) Нежелание "заморачиваться" полным "разруливанием" зависимостей

3) Нежелание разработчиков поддержки бинарных совместимостей и, как следствие, поддержки бинарного репозитария

Плюсы:

1) Неплохая оригинальная init-система

2) Хорошая "разруливаемость" и автоматизация "сырцовых" сборок (ИМХО удобнее чем в rpm и deb)

Т.о. ИМХО база для нормального дистрибутива есть (даже инсталляция с пом. liveCD+stage - очень логично), осталось немного - желание и квалификация разработчиков для доведения до production-состояния (ИМХО и только ИМХО).

2anonymous:

>по-моему зависимости при удаление все еще не обслуживаются, хотя есть средство узнать кто зависит от этого пакета перед удаление.

Уже хорошо, "средство узнать" есть, значит осталось только "желание/нежелание" разработчиков emerge заюзать это средтво при удалении. Идеология? Для меня целостность системы и удобство системы при уситановке/удалении как выше любой подобной идеологии...

>Для меня целостность системы и удобство системы при уситановке/удалении как выше любой подобной идеологии...

Поэтому, пока что, к сожалению, "лучше полдня потерять" (собрать rpm, хотя "полдня" - это на порядок завышено, просто цитата такая:)), зато потом, когда нужно срочно, "за 5 минут долететь":)

>зенитная противоракетная

Это будет покруче "а какой виндовс нужен, чтобы запустить юникс?" :D

2KRoN73:

>>зенитная противоракетная

>Это будет покруче "а какой виндовс нужен, чтобы запустить юникс?" :D

Не, нелогично:)

Портежи в основе своей ports от FreeBSD содержат, а там даже от perl "избавились" (я не фанат FreeBSD, просто это одно из немногих действий, которое мне в их политике понравилось)

PS. Я также и не против perl'а как такового, просто вещи, без которых можно обойтись в базовой системе, должны быть опциональными ИМХО

> о! давно хотел переставить свой немного подзагрязнившийся debian. можно по-пути и эту штучку помучить, посмотреть каким он стал.

Вау! Тут, я гляжу, debian переставлять приходится. ЧТО я слышу! Это как в винде, что ль? Или это только у ламеров переставлять приходится? Дааааааа.... Приехали.

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

Старенькая железка. Офтопик контроллер усб в принципе не поддерживает, дров от производителя, по моему, в природе не существует, а от сторонних производителей - кривые. Офтопик часто синеет=))). А под линуксом пашет как пчелка. Так что проблемы точно не в железе.

2Led & Sincro:

Мож вы в аське пообщаетесь?

графический инсталятор ... чтоб там некоторые не говорили, что его нет .. http://dev.gentoo.org/~agaffney/gli/

А что в 2005.0, пересобирать gcc и glibc по 3 раза (1-й раз для того чтобы скомпилить gcc-3.4, второй раз чтобы с помощью уже gcc-3.4 скомпилить glibc, а третий раз при emerge -e system)
начиная установку с 2004.3 stage3 - не надо теперь?
Неужто теперь наконец стало можно со stage1 прямо устанавливать как в стародавние времена?
Ответьте кто ставил, в Gentoo 2005.0 уже изначально стоит gcc-3.4 ? Да или до сих пор gcc-3.3 ?
Стоит ли качать установочный minimal-cd 2005.0 для того чтобы не трахаться компилить всё 3 раза как в 2004.3 ?

> Ну скажите, мне тогда любители траханья компиляции почему ваш супер пупер дистр не выходит на первые строчки по популярности среди Linux дистрибов. Наверху Шляпа, ...

Таки извини тебе напомнить: наверху -- Винда. Так что все мы тут фанатики...

С уважением -- Смоляное Чучелко

ЗЫ. И тем, кто захочет обратить моё внимание на слово Linux в цитате, отвечу заранее: а среди Gentoo Linux лидирует таки Gentoo...

2DeViL:

>Мож вы в аське пообщаетесь?

А что, разве не по теме?

> 1) Нежелание разработчиков изучения и понимания базовых Unix-утилит и как следствие - лишний python при возможности реализовать то же самое без него.

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

> 2) Нежелание "заморачиваться" полным "разруливанием" зависимостей

про полное разруливание чего-то не понял. При установке все разруливается как надо и даже лучше(потому что гибче) чем в бинарных, что для сорц-бейзд очень и очень хорошо. Отслеживание зависимостей при удалении это очень непростая штука, чтобы реализовать её бытсро и правильно, сам натыкался на проблемы при обновлении отдельных пакетов в rpm-based, когда апгрейд А требовал апгрейда, Б который требовал апргейда Ц , который требовал апгрейда А. Вобщем получалось, что апгрейдить надо было либо всё либо(и не факт что получилось бы) ничего. Попробуй рх 7.3 безболеезненно доапргейдить до фц тест. Посему нужны ли они в обязаительном порядке (завязанные на емердж) это большой вопрос. Сейчас разрабатывается equery который будет выдавать такую статистику по пакетам, которая штатным возможностям рпм и не снилась(опреации как в бд, ВЫБРАТЬ все А КОТОРЫЕ испольют Б и т. д. вероятно бд и будет использоваться, но как надстройка в связи с чем должна ворасти и скорость) так, что что а про нежелание это не по адресу, лучше расскажите чего нового можно увидет в рпм или деб за последние 2-3 года

> 3) Нежелание разработчиков поддержки бинарных совместимостей и, как следствие, поддержки бинарного репозитария

смотрим зеркала генту, везде GRP пустой, это говорит только о том, что это некому не нужно, софт апгрейдится так часто что поддержка всего под все ... ну да про это я тоже уже упоминал, лучше пусть над отлов и фиксение багов в гну софте время потратят, и другие более интересные вещи навроде xdelta (который при бинарном репозитарии саппортить вообще нереальн)

> для доведения до production-состояния

ну вот это могут потянуть и третьи лица вроде vidalinux и спокойно стричь денежку за саппорт