Некоторое время использую Дженту... Очень нравиться этот дистрибутив. Имхо, самый простой и производительный дистрибутив. Очень гибок в настройке - благодаря манипуляциям с переменной USE (что позволяет включать/исключать из собираемых пакетов нужные/ненужные зависимости).
Также благодарая утилите Deltup обновление до пакетов последних версий будет стоить гораздо дешевле, чем в дебиане =). А также еще некоторая оптимизация под архитетуру машины...

Конечно, для установки пакетов в Дженту требуеться больше времени (время на компиляцию), но я даже не обращаю на это внимания :D

P.S. может быть я в чем-то повторяюсь...

Ох уж эти сказочки, ох уж эти сказочники.
она что, бинарники дельтапит?
Или даже если исходники, неужели кто-то будет делать дельту, скажем, с KDE 3.5.6 до KDE 4.0? Если нет, то в чем дешёвизна-то? То, что мне нужно будет скачать 100 MiB бинарных готовых к работе deb-пакетов KDE 4.0, или в gentoo столько же исходников/бинарей?

Прости за непонимание, но при чем тут бинарники? я про них ни слова не сказал
Вообще-то, дельта-пакеты автомотически генерируються специальным сервером (dev.gentooexperimental.org). Мне нужно только отправить корректный запрос (этим-то и занимается утилита Deltup), и подождать пару минут пока генерируется патч, если он еще не был сгенерирован ранее.
Скорее всего у меня будет выбор: либо качать 100М исходников, либо 90-100М патча, не могу сказать точно, поскольку не знаю, что всетаки будет представлять из себя kde 4.0. Но зато для последующего обновления, предположим с KDE 4.0 до KDE 4.0.1-r1, мне потребуеться скачать лишь крохотный патч

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

ok. Т.е. если попросить, дельту kde 3.5.6-4.0.0, пусть и сверхтолстую, от него получить можно?

Ну тогда для справки: официальные дельты KDE Project делаются только для снапшотов и минор-релизов. Именно потому, что с мажора до мажора дельты получатся больше, чем исходники в оригинале.

минор-апдейты - это уж на любителя и лекарство от нечего делать. Собирать дцать часов тот же kde/gnomoe/firefox/openoffice.org только потому, что обновил его за счет "крохотного патча" - это уже маразм. :)

Именно. Теоретически я могу получить даже патч OpenOffice-kde :), только не вижу смысла такой ерундой заниматься.

Не могу согласиться, но и спорить не буду. Я лучше подожду KDE 4.0 и обновлюсь. Тогда посмотрим кто прав :) (Надеюсь что я :) ).

Во первых, новые версии просто так не выпускаются... обычно в них исправляют ошибки, уязвимости и прочие нехорошие свойства крупных проектов. Следовательно возможность дешево обновиться до последней версии - отнюдь не "лекарство от нечего делать"
Во вторых, даже на моем ведре сборка kde с НУЛЯ занимает всего 13 часов (gnome - 6ч, xfce - 2ч, firefox - 15мин, openoffice - 4ч), а из-за небольших обновлений весь пакет не будет полностью пересобираться. Обновиться лишь та часть которая подверглась изменениям.

P.S. Развели тут оффтопик... нехорошо

Да, ладно нормально.
eleet, а вы поподробнее опишите как производятся такие обновления, в смысле не че нажать надо, а технологию. А то я что-то не догоняю. Для бинарников на системах типа Gentoo, FreeBSD такого не сделать, уж слишком сильно отличаются бинарники у конечных пользователей. Для архивов исходников тоже не покатит. Остаются только патчи к исходникам старой версии, которые возможно генерируются на каком-то сервере, архивируются, доставляются вам, затем патчатся ваши старые исходники и происходит сборка уже их пропатченных. Я правильно понимаю?
А вот об этом можно еще по подробнее?
P.S. А вообще весь этот разговор можно вынести в отдельную тему касающуюся Gentoo.

XeNoN, вы абсолютно правы.

Программы в Gentoo Linux устанавливаются из исходни ков. Это чистый текст. Утилита Deltup просто скачивает со специального сайта не весь архив программы, а только разницу между требуемой версией и тем, что у вас есть. На этом спец. сайте имеются все пакеты, которые доступны с официального дерева. Следовательно, если я хочу обновиться с openoffice-2.0 до openoffice-2.1, то emerge (утилита для работы с системой портов, аналог apt) пытается скачать с сервера патч openoffice-2.0-openoffice-2.1.dtu. Сервер проверит наличие этих версий и сделает примерно следущее: emerge получит этот патч и выполнит действия:
Таким образом в системе появиться пакет нужной версии.
#В Дженту этот процесс автоматизирован.

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

И с этим я тоже полностью согласен

Это при условии, что вы не чистите исходники после компиляции, т.е не делаете операцию подобную make clean?
А иначе любое изменение чистых исходников все равно потребует полной перекомпиляции.

XeNoN, вот именно. :) а еще надо умудряться это добро все хранить от компиляции к компиляции. По мне так, больше заморочек, чем вкусностей и приятностей.

Да и насчет сборки OOo на "ведрах" за 4 часа у меня большие сомнения. :)

Ошибаетесь, утилита emerge автоматически выполняет чистку после компиляции. Вам незачем хранить временные файлы.
Вообще, то что обновление до более новой версии происходит быстрее чем сборка с нуля - заслуга людей пишущих ebuild'ы.
Конечно это не всегда так... Я уже писал когда-то, что скорость установки пакетов - не являеться положительной стороной дистрибутива (Если конечно вы не используете уже готовые бинарные пакеты).
#Обычно я ставлю что-нибудь крупное на компиляцию и ложусь спать.

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

Если выполняется чистка, то за счет чего сборка-то ускоряется? Мне это вот тоже непонятно. Вот хочу я, скажем, новую версию linuxdcpp поставить. За счет чего она при обновлении с нуля соберётся быстрее-то, можешь объяснить?

я помимо debian еще много чего использовал и делал :) Да, на gentoo всегда косо посматривал и не пользовался, потому что-то никто из его пользователей никогда до конца всю прелесть этого дистра не обрисовал. А качания и сборки софта по каждому чиху - это меня не прельщает. :)

Ладно, предположим я хочу обновиться с linuxdcpp-20061012 до linuxdcpp-20070403 (хотя в этом случае нету практически никакого ускорения сборки, т.к. пакет очень маленький - всего 328Kb.)
Версия 20061012 отличаеться от 20070403 тем, что первой не хватает некоторых файлов, и несколько десятков имеют разную дату изменения. Так вот, утилита make сама соберет только эти файлы и те которые от них зависят напрямую. А остальные уже были собраны ранее...

P.S. не совсем понял что ты имеешь ввиду под "обновлением с нуля" :blink:

eleet, ну, во-первых, как собирает проект make я представляю. :) во-вторых, в linuxdcpp не используются gnu autotools, но не в этом суть. В-третьих, linuxdcpp маленький, да удаленький. :) Там C++ код и сборка этих "всего 328 KiB" занимает почти 4 минуты на P4 2.4GHz И чудо-ускорение, которое я ожидаю от чудо системы сборки в gentoo, должно проделывать ту же сборку при обновлении с нуля исходников программы ну хотя бы за минуту.

Под обновлением с нуля я имею в виду то, что прошлая сборка была завершена удалением всех объектных файлов (потому что я не хочу хранить до следующей сборки уже не "всего 328 KB", а мегабайтов 5 объектников, пусть даже в архиве). Собственно, я про это:

rmn, я был в этом уверен и поэтому привел его как пример.

В этом случае сборка не будет заметно ускорена. (хотя остаються еще утлиты для сокращения времени компиляции - distcc и ccache)


я уже говорил, что тебе не нужно ничего хранить - emerge автоматически все почистит. Сохраняеться только исходник последней версии, что бы было к чему применять патч :)

:) Вот именно. Поэтому ускоряться нечему и в большинстве случаев пересобирать придется всё заново. Будь то linuxdcpp или OOo. И autotools тут не при чём :)

distcc, ccache и проч. - эти костыли уже не от хорошей жизни в gentoo, можно понять. :lol:

Короче, я уже было поверил в чудо, ан нет его. :(

Если ты считаешь утилиту ccache, которая сокращает время компиляции в 5-10 раз, костылями :diablo: ... то я думаю нам не стоит больше разговаривать :)

P.S. Дабы узнать больше читайте lorFAQ

eleet, :lol: костыли - это образно. Все нормальные линуксоиды могут и без них обходиться в большинстве случаев. А в gentoo без них никуда. :D

lorfaq :) я вообще-то, помнится, в его составлении даже участие принимал.

Добавлено через 1 минуту
ага, бесплатный циркпиар устраиваю. :D

:lol: сплошной флуд пошёл, завтра всё поудаляю.

Так я не понял, всё, что я писал выше - это не аргументы "против"? :D
То, что везде опция, тут - необходимость: длительные установки/сборки по ночам, спец. средства для "лишь бы быстрее собралось". :)

Без всяких утилит типа distcc и ccache, сборка в любом случае не будет ускоренна после очистки объектных файлов, хоть там make, хоть scons, хоть еще что-то.

distcc и ccache тоже ведь не из воздуха берет скомпиленные куски, поэтому хранить все-таки есть что.;)

По мне так эти утилиты тоже бубен, но если кто-то пользуется и кому-то это надо, то значит и не бубен вовсе.:D Хотя я думаю ccache - это больше для разработчиков чем для конечных пользователей. Но это всё моё скромное мнение, Вам решать что использовать.

Мне так совсем не лень все компилить, что-то большое обновляется редко, а всякую мелочь обновлять не долго. Правда, OpenOffice я так и не рискую компилить, ставлю с package. А вот эти гентушные патчи могли бы стать полезной штукой, если бы у меня были проблеммы с получением исходников. Вообще конечно система portage в Gentoo более развитая нежели ports во FreeBSD, но это и не удивительно: взять идею и реализовать хуже чем есть - это постараться надо.

eleet, а как там дела с параллельной компиляцией?



rmn, зато человек привел реальный довод в пользу Gentoo, насчет экономии трафика, хотя это и не существенно для Москвы, Питера и западных стран, но для отдаленных от центра регионов России весьма существенный факт, в том числе и для Петрозаводска - инет-то у многих не халявный.

eleet, вот почитал я темку эту и короче говоря ничего вы так и не поняли, что вам тут пытались рассказать=)

Добавлено через 38 минут
Наверное, для меня эти аргументы - крайне не убедительны :D. ИМХО, длительные компиляции компенсируются оптимизацией под архитектуру и дешевизной обновления.

Кстати совсем не обязательно все это компилировать... если так не любишь ждать, то можешь выкачивать уже готовые бинарные пакеты...
Но я не вижу в этом смысла - если уж используешь source-based дистрибутив, то потратить время на сборку для тебя не должно быть проблемой.

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


Честно говоря, я не увлекался этим вопросом... Мне он кажеться не актуальным для машин с одним процессором.

Ну, об оптимизации под архитектуру наговорено ужо много - это больше миф, чем действительность, которую можно пощупать. :)

А обновления - это уж как посмотреть. Если изначально есть в наличии исходники Debian, то обновления (безопасности, багфиксы) будут весить по несколько килобайт. Но обычно никто не заморачивается и просто делает apt-get update; apt-get upgrade :)

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

Я так же не пытаюсь доказать, что бинарные дистрибутивы лучше, т.к. сам пользуюсь source-based системой. Я константировал факт, что без "бубна" компиляция в разы не ускоряется, т.к. что-то хранить от предыдущих сборок не очень хороший вариант.

Чистится, не чистится - дело не в этом, а в том что исходники таких приложений как OpenOffice, KDE сами по себе в распакованном виде занимают много места + объектные файлы. У меня например несколько гигабайт исходников, если ко всем к ним буду хранить объектные файлы, то они неприемлемо много места займут.

А на процессорах с несколькими ядрами? Пока неактуален, но через пару лет все процессоры будут с несколькими ядрами, поэтому вещь заманчивая. Да и на однопроцессорной машине с одним ядром, например, параллельный make дает ощутимое ускорение.

Да, ты прав - оптимизация совсем не заметна... Но ведь она есть! И это не может не радовать :D
К тому же, нельзя забывать про USE-флаги... Ведь сборка пакета без ненужных зависимостей, сильно ускоряет скорость его запуска и немного скорость его работы...

В Дженту тоже, никто не заморчивается... просто делают emerge --sync; emerge --update :)

Я читал ваш длинный пост в теме "Какой Linux, Unix вы используете?" и писал не о вас. И все же не понимаю, что имел ввиду greiv.

Да действительно - вещь заманчивая. Возможно в скором времени, компиляция какого-нибудь kde будет занимать каких-то 5 минут :D.

Итак, как я и обещал: 3 DVD мартовского среза Gentoo от XOR.
а) доступа к фтп баттловому у меня пока нет. Подождем?
б) когда получится залить, нельзя ли будет с ним поступить так, как с дебианом? Т.е. сымитировать сетевую установку?

Alinaki, /upload открыт на запись всей Карелии :)
Логин/пароль ftp:ftp
Насчет репозитория для сет. установки - думаю, можно организовать. Только если есть какие-то подводные камни, то мне нужна инструкция.

Ок :-) завтра залью. Щас устал и спать.
А вот с инструкциями.... я сам мало что знаю как. Но постараюсь узнать.

Я думаю нужно просто смонтировать эти диски на сервере :). Вот и весь рипозиторий... Как для дебиана :)...

А чтобы им пользоваться надо будет обновить дерево портежей и добаить в make.conf строчку :
(ссылки писал по аналогии с местным репозиторием дебиана)

Вот и все в принципе...

Все три двд в аплоаде. Третий двд в целом не нужен, там квака 4-я и несколько свободных прог для винды - реверанс убунте :-)

готово :)
http://battlefox.ru/gentoo/ (только для Карелии)
сами iso доступны по ftp. Просьба по возможности их не тягать и использовать сетевую установку. :)

помогите с установкой дженту!
проблемы
1) при использовании portageм http://disk.karelia.ru/?f=eleet автоматически скачанные файлы обзываются примерно как "index.html%f=eleet%distfiles%...tar.bz2". при этом portage отказывается сам себя понимать... как избежать присвоения кривых имен при скачивании пакетов?
2) при использовании portageм ftp://battlefox.ru/battle/soft/Linux...entoo-***/dvd#
требуется логин и пароль (как известно). пытался разрулить при помощи .wgetrc - не вышло, пытался при помощи /etc/make.conf: FETCHCOMMAND="wget ... --ftpuser=#### --ftp-password=*******" - говорит логин неправильный, хотя он правильный, короче я совсем запутался!

Вообще проблематично. Нужно
1) обучить качалку понимать http-заголовок Content-Disposition. "Нестабильный" wget это умеет.
2) Качалка должна ходить на disk с измененными User-Agent
вообще-то в этой теме уже писалось, что за gentoo на battle нужно по http ходить.

Насчет ключей ftp-user и ftp-password - попробуй логин и пароль заключить в одинарные кавычки, т.е.
Можно в ~/.netrc прописать логин и пароль, чтоб его не светить и каждый раз в wget не вводить
ну и chmod 600 ~/.netrc сделать. Хотя в данном случае, наверно, .netrc бесполезен ;)

спасибо, как раз догадался что нужно использовать http://battlefox.ru/gentoo
кстати, а в городской сети есть централизованное зеркало gentoo?
может стоит организовать?

sirAndrew, зеркал нет. Если только кто-то сам не захочет его организовать :)

Более того - с батла, скорее всего, gentoo тоже будет скоро удален из-за постоянной нехватки места.

Можно перед удалением открыть iso-образы?