Announcing...

                     Red Hat Linux "Pinstripe"
                           a Beta release

Red Hat. Inc. presents a beta release of Red Hat Linux for your
hacking pleasure.  First, the regular drill:

   This is a beta release of Red Hat Linux.  It is not intended for
   mission critical applications.  It's not even intended for
   non-mission critical applications.  Important data should not be
   entrusted to Pinstripe, as it may eat it and make loud belching
   noises.

Significant changes have been made since the last version of Red Hat
Linux.  We need your help to find and report bugs.  Search for
existing bug reports for problems you find by using bugzilla at:

  http://bugzilla.redhat.com/bugzilla/

Attach patches if you're motivated!

This beta includes so much cutting edge software, the binary packages
come on two iso images.  The installation program now handles reading
packages from multiple CDs.

*  Where can I get this release?

Pinstripe can be downloaded from our public FTP site at:

   ftp://ftp.redhat.com/pub/redhat/beta/pinstripe

With the support of volunteers ftp site administrators, Pinstripe is
available from several mirrors.  The following have complete copies of
Pinstripe, please use a mirror close to you:

North Carolina, USA:
  ftp://metalab.unc.edu/pub/Linux/distributions/redhat/beta/pinstripe/
  http://metalab.unc.edu/pub/Linux/distributions/redhat/beta/pinstripe/

California, USA:
  ftp://ftp.sourceforge.net/pub/mirrors/redhat/redhat/beta/pinstripe/
  http://ftp.sourceforge.net/pub/mirrors/redhat/redhat/beta/pinstripe/

California, USA:
  ftp://ftp.kernel.org/pub/mirrors/redhat/redhat/beta/pinstripe/
  http://www.kernel.org/pub/mirrors/redhat/redhat/beta/pinstripe/

Connecticut, USA:
  ftp://ftp.uselinux.org/pub/redhat/beta/pinstripe/

Indiana, USA:
  ftp://csociety-ftp.ecn.purdue.edu/pub/redhat/beta/pinstripe/
  http://csociety-ftp.ecn.purdue.edu/pub/redhat/beta/pinstripe/

Michigan, USA:
  ftp://mrhankey.bizserve.com/pub/linux/redhat/ftp.redhat.com/redhat/beta/pinstrip
e/

New York, USA:
  ftp://ftp.ee.cornell.edu/pub/linux/redhat/beta/pinstripe

Pennsylvania, USA:
  ftp://carroll.cac.psu.edu/pub/linux/distributions/redhat/redhat/beta/pinstripe/


Pennsylvania, USA:
  ftp://cronus.res.cmu.edu/pub/linux/ftp.redhat.com/beta/pinstripe/

Tennessee, USA:
  ftp://sunsite.utk.edu/pub/linux/redhat/redhat/beta/pinstripe/
  http://sunsite.utk.edu/ftp/pub/linux/redhat/redhat/beta/pinstripe/

Australia:
  ftp://mirror.aarnet.edu.au/pub/redhat/beta/pinstripe/
  http://mirror.aarnet.edu.au/pub/redhat/beta/pinstripe/

Germany:
  ftp://ftp.gmd.de/mirrors/redhat.com/redhat/beta/pinstripe/

Germany:
  ftp://ftp.uni-bayreuth.de/pub/linux/redhat/beta/pinstripe/
  http://ftp.uni-bayreuth.de/pub/linux/redhat/beta/pinstripe/
  
Norway:
  (ISO images only)
  ftp://carroll.cac.psu.edu/pub/linux/distributions/redhat/redhat/beta/pinstripe/


Peru:
  ftp://sajino.terra.com.pe/pub/linux/redhat/beta/pinstripe/

Japan:
  ftp://ftp.kddlabs.co.jp/Linux/packages/RedHat/redhat/beta/pinstripe/

*  What's new in this beta?

   General system improvements:
     o FHS compliant packaging of files
       /usr/man is now /usr/share/man
       /usr/doc is now /usr/share/doc
       /usr/info is now /usr/share/info
       See http://www.pathname.com/fhs/ for more information

     o Document roots for Apache and anonymous FTP are removed from
       /home so it may be automounted.

     o Packages with services are automatically restarted on live
       upgrades

     o Expanded LDAP integration

     o Expanded Kerberos integration

   Core system components:
     o glibc 2.1.91
     o XFree86 4.0.1, XFree86 4.0.1 runtime environment
     o XFree86 3.3.6 X servers included for maximum hardware compatibility
     o GNOME 1.2
     o kernel 2.2.16
     o GCC 2.96

   Expanded hardware support: 
     o Basic USB support (mouse and keyboards)
     o Expanded hardware accelerated 3-D support

   System service changes:
     o inetd replaced by xinetd
     o BSD lpr replaced by LPRng

   A sampling of package upgrades:
     o GIMP 1.1.24
     o Perl 5.6.0
     o Tcl/Tk 8.3.1

   A sampling of Package additions:
     o SDL, smpeg
     o SANE
     o gphoto
     o MySQL
     o AbiWord
     o dia
     o ispell has been replaced by aspell
     o XEmacs

   Next generation development library previews included:
     o pango: Unicode font rendering
       See http://www.pango.org/
     o Inti: C++ foundation libraries including GTK+ GUI toolkit classes
       See http://sources.redhat.com/inti/

Enjoy!

The OS Development Team
Red Hat, Inc.

Почитал, что же там изменено : System service changes: o inetd replaced by xinetd o BSD lpr replaced by LPRng Наконец-то. Не прошло и года ...

Что-то я не понял...

А KDE не включили? И заменили PostgreSQL на MySQL.

KDE2beta3 включили (Korner 1.92). А как скоро сие чудо на Митинском рынке появится, ктонть знает?

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

Tak vrode jasno napisano: "GCC 2.96" ili eto ne RELEASE? :-)

gcc 2.96 - beta
gcc 2.95.2 - release
ИМХО отношение новичка а не нормального человека.
egcs 1.1.2 (и его варианты, которые РХ включало) был замечательный
релиз настолько, что проект gcc переключился на него. gcc2.95 это
уже работа группы egcs.

Для ядра по-прежнему идет egcs aka kgcc. 2.96 - это не релиз.

To: пионервожатый _Tima. А почему так много внимания уделяем RX? Фаворит? Написал бы лучше о предстоящем релизе SuSe.

>To: пионервожатый _Tima. А почему так много внимания уделяем RX? Фаворит? Написал бы лучше о
>предстоящем релизе SuSe.
Pohozhe etot site tak i ostanitsja mestom dlja podobnogo detskogo flejma, nesmotrja na to, chto linki na naibolee
"obsyzhdaemie" temi ybrali :-((

Почему RH?
Потому что лучше :)
Лучше подходит по характеру.
Времена когда можно было запросто заниматься сборкой всех пакетов к добру ли 
к худу ли прошли да и манджеры пакетов ПО важный шаг для аккаунтинга и 
автоматизации. Мне приходится работать с большими сетями, а потому без манджера
пакетов все будет просто в сотни раз тяжелее.
По сему Slackware отпадает.
Mandrake? Это не Линукс а Дизнейланд. Разработчики сосредоточены не на аккуратной
и продуманной сборке пакетов а на рисовании картинок userfriendly пингвина
во всех эпостасиях. Меня это не устраивает.
Caldera? Не далеко ушла от Mandrake
Corel? Без Enlightenment/Гнома скучно а КДЕ не для меня. Да и направленность на
десктоп юзеров, а я к таким себя не причисляю.
SuSE? Возможно вполне скоро из этого дистрибутива и получится альтернатива RH
пока же, для меня он такой не является. Те же проблемы в принципе. Не до того
вылизаны пакеты как в RH не то качетство патчей, КДЕ во главе стола. Грусно,
уважаемые за каждым апдейтом бегаеть в магазин с 30$.

Debian? Это бесспорно альтернатива. Несколько задумчивые руководители проекта
но это можно пережить. Я к RH привык больше.

Почему RH? Потому что дистрибутив самый продуманный. К примеру, сравните время и обьем 
установки RH с другими. RH поставить 15 минут, всех остальных не менее 30-ти.
Когда ставятся десятки компьютеров за раз это играет большое значение.
RH регулярно выпускает что то интересно и новое, приносит новые идеи в мир
дистрибутивов Linux.
Будучи хорошо знакомым с привычками RH мне стоит менее полуторачасов времени
чтобы довести дистрибутив до такого состояния в котором я его смогу использовать.
За вот уже 4й год обшения с RH притензий к дистрибутиву не имея, более того,
с каждым новым релизом на сердце становится легче от появления полезных фичь,
нового уровня стабильности и интересности.

Кстати Pinstripe поставился успешно и вызывает только положительные эмоции.

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

Лично мне RH не нравится тем, что его авторы пытаются скрестить ежа с ужом. Менеджер RPM, по крайней мере в 6.2, это редкостное по кривости явление. Он делает то, что должен делать сам пользователь, затрудняя контроль над системой. Тривиальный пример. В нормальном дистрибутиве или руками Qt ставится по умолчанию целиком в каталог /usr/local/qt. Это означает, что достаточно переименовать этот каталог, чтобы получить возможность держать несколько версий Qt. Плюс юзер сам добавляет /usr/local/qt/lib в ld.so.conf => он лучше представляет, как устроена система. Плюс любому ./configure можно сказать, чтобы он искал Qt в каталоге /usr/local/qt-2.1.1. Все красиво, логично и удобно. Так нет же! Что делает RH? Он ставит moc в /usr/bin, libqt* в /usr/lib, а хедеры в /usr/include/qt! Естественно, теперь уже сам черт в этой системе ногу сломит, авторам открытых Qt-программ в configure.in приходится явно добавлять поддержку RedHat, а юзеру, абстрагированному менеджером RPM от реального состояния проблемы, становится намного сложнее что-то поменять. За исключением того, что он может написать rpm -e один-пакет; rpm -U другой :) Вторая неудобная вещь в RH это неоправданный перекос в сторону Gnome. Казалось бы, любому здравомыслящему человеку понятно, что ничего хорошего от объектно-ориентированной системы, написанной на структурно-ориентированном C, ждать нельзя! Они бы еще на Бейсике ее писать стали. Так нет же, Gnome мы ставим по умолчанию, а KDE только если очень попросить.

Третье. Использование RPM неявно предполагает, что из исходников ничего собираться не будет. Потому что эта система умеет проверять файл на наличие в базе данных RPM, но не умеет проверять dependencies на их физическое существование. Это еще более криво, чем система установки в Windows, где недостающие файлы можно ставить руками. А то, что база данных RPM слетает после 1-2 установок с --force, это воообще предел талантливости...

Я регулярно собираю пакеты на базе патчей из SRC.RPM,
также регулярно пользуюсь флагом --force, база не слетала никогда,
depecndencies не помеха есть флаг --nodeps.
ИМХО Qt как одной из основных библитек системы не место в /usr/local
более того /usr/lib/qt-x.x и /usr/include/qt-x.x самое оно,
./configure --with-qt-lib=/usr/lib/qt-x.x --with-qt-include=/usr/include/qt-x.x
сделать не тяжело.
Пример с qt не подходяший.

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

K философии RH без сомения нужно приспособиться, но приемушества этого
дистрибутива стоят небольших затрат умственных усилий.

А мне кажется что времени на исправление РедХатовских ошибок в
скриптах уходит гораздо больше чем на полную настройку
Слаквари... никто не спорит что РедХат стал практически стандартом
линуха, но место его только на рабочих станциях т.к. ставить
на сервер систему с таким количеством ошибок - это обречь себя
на постоянный и непрерывный апгрейд пакетов... а если сервер
должен работать непрерывно и таких штук десять то прикинь
сколько это отнимает времени... к томуже разбираться в РедХатовских
конфигах и пускачах это еще то занятие... в этом отношении
Слакварь продумана гораздо лучше и имеет стройную структуру,
что позволяет с минимальными затратами времени изменять любые
параметры системы путем исправления руками небольшого кол-ва
конфигов... поэтому я считаю что Слакварь - это наиболее удобный
_серверный_ дистрибутив (хотя у меня и рабочая машина под
Слакварью тоже)... так что нет идеала в этой жизни :)) или
каждому - свое... при желании и наличии знаний/рук можно
настроить под свои нужды _любой_ дистрибутив... это дело вкуса
что выбирать...

Граждане, давайте вначале чего то знать
а потом писать в народно доступную эху
все нормальные админы и создатели пакетов
должны знать что /usr/local/ -- для локальных пользователей
ш пакет не должен содержать файлы которые записались бы туда

А что, разве редхат запрещает ставить пакеты из исходников ? Или он запрещает писать в ld.so.conf ? Если уж попался такой пакет - удали его из rpm'ок и поставь ручками. Кстати сколько вы можете насчитать в своей системе пакетов, которых нужно держать несколько версий ?

P.S. Кстати как вы предлагаете строить проверку на физическое существование файла в системе ? В каких каталогах ? Напоминаю - rpm'ка создается производителем, который понятия не имеет о структуре каталогов на вашей машине (они все таки иногда различаются достаточно сильно). Пример - в каких каталогах вы искали бы libqt* ? Find здесь явно не подойдет - слишком долго, а locate стоит не у всех, и настроен не на все каталоги. Вот и получается, что искать файлы надо в какой нибудь базе данных, которой и является rpm. Ну либы можно еще ldconfig'ом поискать.

dlya etogo peremennyie okruzheniya sushestvuut, vrode $LIBPATH. a esli po subju, to lu4sheb oni yadro 2.4 pripayali, raz uzh vse tam beta.

ядро 2.4 есть в виде отдельного rpm'а (и оно не ставится по дефолту).

/usr/local/ - это не для локальных пользователей, а для пакетов, не входящих в дистрибутив. Только и всего. Отделение вендорской части от местной самодеятельности.

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

Anonymous валил бы ты гнать в какое-нибудь другое место, например www.hackzone.ru
Не нравится не читай, сколько раз можно повторять.
Не для тебя написано так и не лезь.

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

for timur

Да почитал я это дело :) >P.S. Кстати как вы предлагаете строить проверку на физическое существование файла в системе ? В каких >каталогах ? Напоминаю - rpm'ка создается производителем, который понятия не имеет о структуре каталогов на >вашей машине (они все таки иногда различаются достаточно сильно). Пример - в каких каталогах вы искали бы >libqt* ? Find здесь явно не подойдет - слишком долго, а locate стоит не у всех, и настроен не на все >каталоги. Вот и получается, что искать файлы надо в какой нибудь базе данных, которой и является rpm. Ну либы >можно еще ldconfig'ом поискать. По поводу qt, Тимур попробуй у себя в консоли набрать $QTDIR У меня например выдает bash: /usr/lib/qt: is a directory Это все к тому что разработчики когда распространяют программы в RPM про такие и подобные вещи обычно знают, или же это дерьмовые разработчики Но лично я сижу под слакварью и пока меня это пока устраивает

Круто, способ найден - "попробуй у себя в консоли набрать $QTDIR У меня например выдает bash: /usr/lib/qt: is a directory". Я не спрашивал, как мне найти libqt в своей системе. Я просил придумать что нибудь универсальное для проверки физического существования файлов rpm'ом. Кстати говоря ваш пример даже для человека не подходит. У меня переменная QTDIR не установлена, не смотря на то, что libqt у меня стоит и licq работает превосходно и не глючит. Вообще переменные окружения это не выход. Эдак придется к каждому rpm'нику писать инструкцию для установки типа установи следующие перменные окружения... Кстати qt у меня установлена с rpm'ника, и как прикажете при установке rpm'а модифицировать переменную окружения ? Shell'ов разных много, для всех не придумаешь. Slack - это конечно хорошо. Но я licq+qt поставил на свой P166 за 3 мин, а тратить время на сборку пакетов, которые не критичны я не собираюсь. И потом я хочу быть уверенным в uninstall'e, хочу иметь возможность в любой момент узнать, какой файл из какого пакета куда встал. Челу, написавшему про LIBPATH: Придумай что нибудь для поиска файла IPChains-HOWTO. Устанавливать переменную DOCSPATH ? А как с подразделами в ней ? Искать по всему дереву каталогов ?

Блин, народ, я пользую Debian и не жалуюсь
там всё выдержано по стандартам FHS2.1
и файлы я у себя ищу по locate
а если недавно появился -- то я запускаю find
и переменные окружения у меня выставлены по минимуму
зачем мне указывать что qt у меня в /usr/lib/qt2/
если программа его и так найдет через ld.so
и как у rpm-ки показать список установленных пакетов
с их текущим статусом и кратким описанием (аналог dpkg -l)
или вывести список файлов в пакете ( dpkg -L package)
или ..
да хватит в принципе
у каждого есть чем гордится или наоборот, я не утверждаю что Дебиан
это панацея или самая круть но и в ней можно как и в слаквари
самому скомпилить свой пакет со своими опциями
и даже проинсталить его как .deb
поэтому говорить что слак -- это конструктор и никто больше это
несколько преувеличено, всё зависит от администратора этой системы
я базируюсь на Дебиане, шапка мне не понравилась ( так же в принципе
как и CorelLinux)
P.S. все вышеизложенное естесственно IMHO

В догонку

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

>А как скоро сие чудо на Митинском рынке >появится, ктонть знает? Появилось уже :~Ё Я купил даже, а это оказался 6.0:( Интересно, какие же сволочи это делают...

egsc = beta gcc! Ша! Я gcc и egcs сношал во все дыры... И они меня. Просто egcs есть добавленные необходимые фичи + непофиксенное несоответствие стандартам ANSI. И получалось, что проги, написанные под egcs на RH 5.2, например, не собирались под gcc 2.7.2 по соображениям недостатка фич, а на gcc 2.95.2 не собираются по причине всягого дерьма типа неявного преобразования типов!!!! Мочить блин за такой разврат!!!! Более того - egcs пишется как девелоперский, и, естессно, не на все платформы перенесён. Вот так то! И нефиг тут пальцы растопыривать - RH как был всегда жутко удобной подставой, от которой когда хочешь отказаться - то поздно, так и остался! А rpm - рулезз! Пока нет BSD ports под линукс, rpm рулит! :))))))))))

По поводу разнесённого в обычные катологи qt. Вы видели, как FreeBSD ставит qt и qt2? Правильно. Как RH. Только ещё безумней. появляются такие новшества, как moc2 :)))) Но это всё фигня - поправил configure, всё встанет на места.

Народ, объясните чем отличается редхатовский enterprise kernel от нормального? Раньше он вроде только в enterprise edition был, а сейчас в бету выложили.

И вот так всегда - о красном колпаке все только и говорят. О выходе Debian Potato столько не пишут... Жалко

Shadow, FYI egcs 1.1.2 лично я использую на Solaris и Linux в достаточно
приличных масштабах, если учесть какое колличество пакетов необходимо
собирать на Solaris для того чтобы привести его в божеское состояние
удобное для работы.
gcc 2.7.x безнадежно устарел как и egcs 1.1.2 плохо вот только что переход
на gcc 2.95.2 не так прост как хотелось бы. Однако уже пора...
Да и весь upgrade 6.2 в 7.0 будет тяжолым.
BSD ports - дешовый примитив. RPM не самый лучшей package manager но имеет
все необходимые возможности чтобы упростить содержание большого колличества
машин.

Ответ на вопрос Vikingа о том чем отличается сборка RH ядра от обычной.
1) продуманный конфиг. От RH кофига отталкиваться очень просто - загрузить
и убрать то что тебя не интересует, дело идет гораздо быстрее.
2) продуманный набор патчей прошедший внушительный период тестирования.
RH сборка ядра содержит около 40 патчей адресуюших различные текушие проблемы
ядра Linux которых немало. Например, PIII поддержка, rawio, raid и так
далее.
3) сборка ядра от RH ориентирована на сервера. Один из патчей которые прилагает
RH содержит изменение нединамических параметров для ядра которое будет
использоваться на серверных системах. linux-2.2.16-server-tuning.patch

Пиплз! А кто знает, где взять точный списочек патчей, стоящих на дефолтовых ядрах RedHat 6 и Mandrake 7 (2.2.14?) А то хочу пересобрать ядро до 2.2.16, но собрать его с чистого ядра плюс самостоятельно добавленные патчи - то есть полная самодеятельность. Где взять список патчей, добавляемых в вышеупомянутые ядра и где взять собственно эти сами патчи? Есть вообще может какой ресурс в Сети по патчам ядер?

2shankara:
Говорят обычно о том, что можно поругать или наоборот что охота
вытащить на поверхность как самое рульное
А с Debian'ом -- там что
там все работает
ругать его особенно не за что
вытаскивать на поверхность ?
так он и так там :)

2Tima: Вот блин и я про то же... Не использовали бы в масштабах, не было бы проблем с переносом. ИСПОЛЬЗОВАНИЕ beta В МАСШТАБАХ РАЗВРАЩАЕТ И ВЕДЁТ К НЕПЕРЕНОСИМОСТИ! (это я о gcc). Релизы используйте! И сверяйтесь со стандартами :( По поводу ports - дёшево, а чего там примитивного? работает именно так, как требуется, и НИКОГДА не возникает проблем с несовместимостью. Правда, их надо обновлять хотя бы раз в два месяца :) И никогда не возникает спора "у кого больше" - весь софт всегда свежий.

этот ресурс называется SRPM

Флейма о Debian нет только потому, что ... (нехорошие люди) со Слакварью и BSD не узнали, что там удобно ставить пакаджи. Они постоянно плюют туда, где что-то удобнее, чем у них. Ведь неудобство пользования системой --- признак ее крутости. Не так ли? :-)

насчёт Слакваревских пакетов.. действительно удобно.. простой .tgz с файлами в тех папках в каких они должны быть в системе.. и doinst.sh так что если что то можно подправить.. :) ведь sh со всеми совместимый.. :) инсталить installpkg сносить removepkg не проверят по тупому как РМП наличие библиотек.. :) например у меня РПМ ругнулси что нету у меня глибс 2.1.0 хотя Слэк7.. ну а форсе... это в любом случае не корректно.. хм. еще одна фича или я совсем туп или как но ведь когда собираешь новый софт он автоматическип при инсталле добавляеться в /var/log/installed_packeges? %)) а кому не нравиться installpkg и remove* то есть удобный setup и там можно всё что нужно поставиьт или посносить.. :)

nu vo blin, o chem eshe budem sporit? delat nechego kak sporit kak pakety stavit lutshe, kto kak lubit tak i stavit, RPM eto konechno no vse vsegda priemlimo, ya dlya svoih system delau tak, sperva na odnoi mashine kompilyauu potom ne drugih libo metodom tar.gz libo cherez NFS delau i bez osobyh problem. Na solarise i togo proshe, pkgadd -d ./current_package na aix-e est smit, strashno udobnaya vesh

Сами патчи можно смело брать из kernel-2.2.x-y.src.rpm, там же в .spec смотреть порядок их приложения. Я лишь с небольшими исправлениями поверх всего, что RH в последний апдейт 2.2.16 закатали, приложил udma-patch, e2compr, reiserfs, international crypto, и получил все, что мне нужно (то есть, уже с raw device, bigmem, и всем таким прочим).

А может где-нибудь такие пропатчиные ядра выкладывать?? Чтобы зря не мучаться, а то пока devfs,reiserfs,... и прочие прикрутят к ядру уже помрешь...

Ну ка напомни основные библиотеки Линукса? QT никаким боком туда не лезет. RH - тек, поделка. У меня стоял 6.0 до Дебиана 2.2, так у него крон отрубался после установки даты в нормальное состояние и применения hwclock. И требует скорее не умственных усилий, а усилий перейти на более нормальную систему. На тот же Debian or FreeBSD.

Ну на счет 6.0 речи нет это конечно глюкодром был поспешили они с выпуском а вот 6.2 очень прелично получилась я надеюсь что и 7.0 в релизе будет хороше отточена и класно работать !!! Я перепробовал много дистрибутивов: много клонов редхата, слаквар, корел !!!Для разных целе дома нужен десктоп на работе сервера(разного характера)!!! Но мысли только одни что редхат достаточно хороший и централизованный дистрибутив!!! Его легко настраивать и поддерживать!!! Про слаквар я молчу потому что настроив свой сервер на редхате и потратив на отладку около недели со слакваром я кавырял каждый сервис чтобы он дал мне такиеже возможности что я сделал на редхате, в течении месяца!!! И то я не добился стабильености что то всеравно периодически вырубалось я не мастер слаквара конечно но столько сложностей не ожидал!!! Про дебиан сказать ничего не могу так как он у меня стаял в реализации корела и то дома пару недель!!! Так что отсюдо мораль каждый пользует что настроить может:-)

И нефиг крошить батон на BSD ports. Лучше его нет и не будет никогда. Поясняю на примере: Мне нужно установить, скажем, mc. Иду в каталог /usr/ports/misc/mc Делаю: # make install Что при этом происходит ? Первым делом, она проверит, есть ли файл 'mc-4.5.51.tar.gz' в каталоге /usr/ports/distfiles. Если его там нет, то она его скачает. К каждому port-у прилагается список мест, где можно скачать нужные файлы. Так что она его найдет, даже если несколько основных сайтов загнутся. Если не найдет, то его можно раздобыть любым путем и положить в distfiles. Кстати, ports у меня всегда поддерживается в актуальном состоянии при помощи CVS. Так что я всегда буду иметь последнюю версию программ, не задумываясь об этом. Если в port-е не последняя версия, значит последняя версия еще недостаточно стабильна. После скачивания файла(ов), она обязательно проверит его контрольную сумму (на случай, если его подменили). В случае несовпадения сумм будет выдано предупреждение и установка прервется. Можно сказать ей, что-бы она суммы не проверяла, если известно, что все в порядке. После распаковки исходников на них будут наложены все необходимые патчи (они идут вместе с port-ом). В том числе и патчи для безпроблемной компиляции под BSD. Затем она проверит наличие необходимых файлов. В BSD все на своем месте. Если это исполнимый файл, он должен быть в PATH. Логично. Если его нет в PATH, то программа его тоже не найдет. Соответственно библиотеки должны быть в /usr/lib и /usr/local/lib. Аналогично и другие файлы имеют свои места. Все что находится в основном дереве (идет в дистрибутиве) лежит в /usr, все что ставится из пакетов и протов лежит в /usr/local. Всегда. Для сборки mc нужны библиотеки glib12.3 и intl.1 Если их нет, то прежде чем продолжать сборку она установит соответствующие порты. Автоматически будет вызван configure (если нужно), make и make install. Затем в системе будет зарегистрирован package -- mc-4.5.51 . И все файлы к нему будут приписаны, так что uninstall делается стандарнными средствами. Кстати, можно вместо make install делать make package. Получите пакет -- mc-4.5.51.tgz, можете его потом на другой системе ставить. В общем, это пракитчески безпроблемная вещь, в отличии от rpm, который неизвестно кто собирал. Неизвестно где и из чего. IMHO, тот кто понял как пользоваться ports, тот уже никогда не станет пользоваться никакими другими средствами по своей воле.

Блин ну не ужто все еще не поняли что самый хороший дистрибутив/система тот к которому привык. И не черта флэйм разводить там где крутизну нельзя померить циферками конкретными.

Извините, старого масдайщика, но, на мой взгляд, енто всё дур дом. Пакеты там пакеты тут... Пока в линуксе не появится нормальных инсталляторов, юзать его будет сплошное мучение. Что в моём понимание нормальный инсталлятор? Пользователь качает один(!) файл, затем запускает его. Разработчик указывает в этом файле, какая библиотека, какой версии ему нужна, а инсталлятор выставляет пути. Если библиотеки в системе нет, то инсталлятор ругается, а разработчик может сообщить, где её взять. Естественно в каждом дистрибутиве свой инсталлятор, а передаваемый файл имеет один формат. А пакеты под каждый чих это плохо.