...бо толстые (типа SuSE/Fedora/CentOS) слишком много хотят.
Хочется грамотно построенных пакетов, и что бы минимальный инсталл не превращался в 600M занятого пространства (причем даже без иксов), из которых 500M вс╦ равно никому нафиг не нужны. Прич╦м, проблема не в месте, нет (его вайлом) - но не хочется что бы болталось то, что явно не используется, а включено просто по растяпству того, кто строил RPM (ибо ему лень посмотреть, что _реально_ нужно пакету, так что он молча лепит вс╦, убирая только явные циклы).
Есть такие в природе? Может, какие новые, не очень известные проекты?

> RPM-based современный дистро
> Хочется грамотно построенных пакетов
- Улыбнуло.
В принципе, тебе ничто не мешает при инсталляции той-же Зуси, не выбирать пакеты которые тебе не нужны.

Ты ошибаешся, это делается не по _растяпству_ или незнанию, а совершенно из других соображений.

В принципе, тебе ничто не мешает при инсталляции той-же Зуси, не выбирать пакеты которые тебе не нужны.
Угу, не мешает... Только если я убираю вс╦ что мне не нужно, убирается и base Попытки оставить абсолютный минимум ни к чему не приводят... Например, я понять не могу, зачем поддержка TTF нужна в абсолютно текстовой инсталляции...
Ты ошибаешся, это делается не по _растяпству_ или незнанию, а совершенно из других соображений.
Мне всегда было жутко интересно, по каким именно. Например, попытка убрать pcre из CentOS 4.4 привела к тому, что было предложено убрать почти вс╦ остальное (при минимальной инсталляции), прич╦м практически все из них явно не нуждаются и не используют pcre (например - sysklogd, а всего почти 200 пакетов).
Почему билдеры пакетов в SuSE (и не только( делают cut&paste на строки BuildRequires, мне тоже совершенно непонятно, равно как и непонятно, каким раком cyrus-sasl имеет отношение к построению ipsec-utils (это для иллюстрации)... Если это не незнание, растяпство или лень - то что это такое?
А особенно мне непонятно, почему CentOS, выросший из RHEL, который считается супер-стабильным, имеет в дистре ipsec-utils хз какой версии (0.3.3 кажется, уже давно есть 0.6+), которая что угодно но не стабильная... Ну и т.д....
Просто обидно, что приходится тратить сво╦ время на всю эту фигню... Вместо того что бы поставить и забыть (ну почти)...

Пардон за съезд, а почему именно RPM-based?

Это называется rpm hell. Именно из-за этого я перешел в свое время на slackware. Рекомендую попробовать. Все слухи о сложности и "избраности" данного дистрибутива сильно преувеличены.
---
ЭТО надо обкашлять ! (2:5020/159.17)

> Почему билдеры пакетов в SuSE (и не только( делают cut&paste на строки BuildRequires, мне тоже совершенно непонятно, равно как и непонятно, каким раком cyrus-sasl имеет
> отношение к построению ipsec-utils (это для иллюстрации)... Если это не незнание, растяпство или лень - то что это такое?
Это результат привычки иметь в системе "все разом".
---
Причина возврата изделия: Работает, но не включается.(2:5063/1.5)

> Только если я убираю вс╦ что мне не нужно, убирается и base
- Если ч╦тко представляешь что именно ты хочешь, не проблема. Игнорируй зависимости и ставь только необходимый минимум.
> Почему билдеры пакетов в SuSE (и не только( делают cut&paste на строки BuildRequires, мне тоже совершенно непонятно, равно как и непонятно, каким раком cyrus-sasl имеет отношение к построению ipsec-utils (это для иллюстрации)... Если это не незнание, растяпство или лень - то что это такое?
- Это скажем так, философия построения дистрибутива. Если она тебе не нравиться у тебя всегда есть выбор.
Бинарный, маленький, современный, с грамотной системой управления пакетов, - дорога тебе в ArchLinux только это не RPM и...

Пардон за съезд, а почему именно RPM-based?
Потому что, при грамотном использовании, это удобный тулз, с весьма хорошей функциональностью.

> Потому что, при грамотном использовании, это удобный тулз, с весьма хорошей функциональностью.
Судя по вышеприведенным притензиям сей удобный тулз никуда не годится.
Возьми слаку и не мучайся.
---
Пpежде чем стиснуть зубы, покажи язык.

Это называется rpm hell. Именно из-за этого я перешел в свое время на slackware. Рекомендую попробовать.
Это так называется по причине лени тех, кто делает дистры Можно ведь вс╦ сделать грамотно, при желании. Только очень нудно и нужно очень узкому кругу людей...
Со Slackware я знаком ещ╦ с первых версий - не устраивает как раз отсутствие нормального PM, не устраивает "голое" ядро, не устраивает отсутствие всего того, что есть у RH и SuSE - команды разработчиков и баг-фиксеров, которые из сырых пакетов (включая ядро) делают что-то чуть более приличное (хоть и не всегда, но в целом вс╦ же).

Судя по вышеприведенным притензиям сей удобный тулз никуда не годится.
Да нет же. Тулз сам по себе годится - но то что вокруг навертели - не годится Про слаку я уже сказал

По-моему, apt удобнее. Из личного опыта.

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

И что за проблемы с пакетным менеджером в слаквари? А поставить swaret или slackpkg, так они и зависимости будут проверять. Еще и aпгрейд из сетевых репозитариев - сунул в крон и не нет проблем. Сборка собственных пакетов - проще не бывает: configure, make, checkinstall, installpkg ... А при обнаружении дырок очень быстро выходят обновленные пакеты, спасибо Патрику и пользователям, которые шлют багрепорты и патчи.
Если уж нужен специализированый дистр с grsecurity, допустим, то тогда уж генту лучше ставить.
---
Баги на заказ ! А.О." Красный Чайник "

Нет, это пока не навязчивая идея - это была просто идея - вдруг кто-то додумался _правильно_ его использовать Но, судя по всему, это были напрасные надежды...
А RPM (по задумке) был хорош. Идея PM как раз в том и была, что бы отслеживать зависимости и ставить только то что нужно, автоматом делать апгрейды/апдейты etc, но если дистростроители предполагают, что все пользователи ставят все пакеты разом вс╦ равно - то какой вообще смысл использовать PM?
Меня возмущает сам подход к делу, когда на свежезаказанном хостинге на DS ставят _полный_ набор всего, включая гном и kde, которые там использоваться не будут... А ещ╦ народ возмущается вынью - типа, дофига лишнего... А получается, что что бы в линь не было лишнего, нужно ставить вс╦ ручками. Нет, это само по себе не проблема (по крайней мере для меня), но это автоматически значит, что мне нужно _лично_ (или поручить кому-нить) отслеживать все SA и заботиться о судьбе инсталляций (о каждой в отдельности - если нет PM, кстати)... Глупо, имхо. Не говоря уже об отсутствии времени - это ведь не моя работа, в конце концов...

Кстати, слакварные пакеджменеджеры отслеживают зависимости по принципу - минимум что нужно. Через ldd.
---
Планета бибисяка: пива нэт, ФидоHэт, населена юзвеpями

Глянул на слакварь... И что я вижу?
The newest release of Slackware, version 10.2, is available now. - этой "новости" уже год... Ладно бы просто новости, но дальше:
Slackware 10.2 includes the Linux 2.4.31 kernel, with Linux 2.6.13 available in the /testing directory.
И далее... В дистре практически все пакеты датированы прошлым годом, а некоторые вообще 2004 года... Это, блин, суперсовременный дистр... Такой подход говорит об исключительной осторожности авторов дистра... Или об отсутствиии времени на его поддержание.
Сборка собственных пакетов - проще не бывает: configure, make, checkinstall, installpkg ...
Угу, и молиться что бы ничего по дороге не было задето. Т.е. нужно убедиться в этом лично. Чего я и хочу избежать, собственно.
Если уж нужен специализированый дистр с grsecurity, допустим, то тогда уж генту лучше ставить.
gentoo? лучше уж slackware :)
grsecurity не решает всех проблем, увы. Оно даже малой их части не решает, не говоря уже о том, что selinux в этом плане мощнее. Но я имел в виду весь комплекс патчей к ядру, которые делают его стабильнее, а не только ужесточение контроля доступа.
Впрочем ладно. Как видно, выбора у меня особо нет... Гляну на ArchLinux - идея хорошая, но что там внутри...

Цитировать вс╦ не буду ибо утомительно. Если вкратце, то я уже не улавливаю, ход мысли и непонятно откуда и на ч╦м основаны такие далеко идущие выводы. По сабжу я уже собственно сво╦ мнение изложил, приятного флейма на тему бестолковых майнтейнеров.

Предлагаю ознакомится с политикой выпуска релизов и узнать, что такое slackware-current (11.0 RC5). Последние обновления в 10.2, кстати, датируются 29 сентября 2006, обновление openssl, так что за дистрибутивом следят.
> Угу, и молиться что бы ничего по дороге не было задето. Т.е. нужно убедиться в этом лично. Чего я и хочу избежать, собственно.
Вы о чем?
> grsecurity не решает всех проблем, увы. Оно даже малой их части не решает, не говоря уже о том, что selinux в этом плане мощнее. Но я имел в виду весь комплекс патчей к ядру,
> которые делают его стабильнее, а не только ужесточение контроля доступа.
Если такие жесткие требования к ядру, то чесно говоря, странно слышать о поиске идеального дистрибутива. Ядро в таких случаях собирают сами, тщательно отбирая патчи.
---
ЭТО надо обкашлять ! (2:5020/159.17)

RPM слабее того же APT, не понимаю, почему RPM тебе нравится. Посмотри в сторону Debian / Gentoo. RPM-based заставляют периодично переставлять дистр, перенакладывать патчи на пакеты. Нафиг надо? Если не нужны лишние зависимости бери Gentoo.

Вы о чем?
О том, что тупая компиляция и установка пакета иногда приводит к проблемам в уже работающей системе - из-за несовместимости изменений в новых версиях со старыми версиями. Да, так бывает сравнительно редко - но бывает.
Ядро в таких случаях собирают сами, тщательно отбирая патчи.
Или берут готовое, с патчами, которое удовлетворяет требованиям, и за которым следят (RH/SuSE). Это весьма непросто - собрать ядро с нужными патчами, если треть из них конфликтует друг с другом. Если приводить аналогию... Я хочу ездить на машине, а не быть автомехаником, даже если я знаю как она устроена и когда-то этим самым автомехаником и был.

RPM слабее того же APT, не понимаю, почему RPM тебе нравится.
Чем? Примеры можно?
RPM-based заставляют периодично переставлять дистр
Не заставляет, если не делать апгрейд. Апдейты идут без переставления дистра - у меня ещ╦ где-то стоит SuSE 8.2, вс╦ обновляется без переставки (патчи etc). Сам по себе RPM ничего не заставляет - я уже говорил. Простой факт наличия молтка не предполагает забивания им шурупов, хотя и не исключает такой возможности, не находишь?
Если не нужны лишние зависимости бери Gentoo.
Любой дистр, расчитанный на ручную сборку пакетов меня не устраивает по определению. Так что если нет готового, нужного мне, с заданными свойствами - может быть, прид╦тся начихать на "лишний вес"...

Ну ты прям непримиримый какойто :) Спрашиваешь - тебе отвечают - ты тут же "отбиваешся" :) :) Зачем спрашивать тогда ... ты ведь все и так знаешь ... умник :) . Объясни лучше мне чем dpkg хуже rpm . Сдалось тебе это RPM .

Спрашиваешь - тебе отвечают - ты тут же "отбиваешся"
Если уж строго подходить - то мне не ответили на вопрос Точнее, из ответов стало ясно, что на мой вопрос ответа нет. А отбиваюсь потому, что мне хочется именно то, что мне хочется, я даже объясняю, почему - в надежде, что найд╦тся решение. У меня есть определенные требования к дистру, и не хочется из них вылезать, и в то же время, мне не хочется тратить сво╦ время на создание своего дистра. Да-да, и рыбку съесть, и...
Объясни лучше мне чем dpkg хуже rpm
Например, тем, что он привязан к Debian, а дебиан (фактически) м╦ртв. Достаточно посмотреть что туда входит и какой оно давности. Впрочем, основная причина - я не люблю иметь дело с фанатиками - а создатели debian фанатично помешаны на идее GNU в частности и "чистого" Open Source в общем. Но на самом деле - это неприципиально, чем. Мне он не нравится, а функционально он не лучше чем RPM - пусть будет такое объяснение.
Я не хочу вести религиозные войны, равно как и спорить чем яблоки лучше апельсинов. Меня _устраивает_ RPM (как инструмент), и поэтому _хочется_ именно его. Если мне _убедительно_ покажут, что есть что-то _принципиально_ лучше RPM (а не на уровне "армяне лучше чем грузины"), с _готовым_ _современным_ дистром, где все пакеты _текущие_ (а не годичной давности), где создатели дистра думают не только о себе, но также о других - я рассмотрю этот другой вариант. Пока же (если исключить "тонкость" и сумасшедшие зависимости) ближайшим приближением к моим требованиям является Fedora Core и SuSE 10.
Ещ╦ раз напомню - дистр _не должен_ быть расчитан на то, что сборка будет происходить вручную. Это хорошо для практикующихся сисадминов, а не для работы, особенно когда таких систем много, и их нужно поддерживать в рабочем состояннии _одновременно_. У меня, увы, нет штата сисадминов, что бы всем этим занимались...

- Вы хоть сами понимаете что пишите? Не смешите людей.

- Никто Вас ни в ч╦м убеждать не собираеться, Ваши "пристрастия" - Ваше личное дело.

- Если человек не хочет слышать, то он и не услышыт.

> Чем? Примеры можно?
Наличием выбора веток дистрибутива, возможностью автоматической закачки и установки всех необходимых зависимостей при установке пакета, возможностью указания источника пакетов, где APT будет производить поиск пакетов, прич╦м, источниками могут быть не только сетевые ресурсы, апгрейд всего дистрибутива одной командой, возможностью иметь смешанную систему из разных веток, автоматизацией маскирования конкретного пакета при адейтах / апгрейдах для избежания обновления данного пакета, умением автоматически устанавливать необходимое для компиляции при ручном создании пакета, и развитыми средствами для получения информации о пакетах.
RPM по сути это средство для сборки/установки/получении информации одиночного пакета.
> Не заставляет, если не делать апгрейд. Апдейты идут без переставления дистра - у меня ещ╦ где-то стоит SuSE 8.2, вс╦ обновляется без переставки (патчи etc).
Ммм, а как, например, "патчами и etc" происходит процесс обновления Glibc? Проблем не возникает?
> Любой дистр, расчитанный на ручную сборку пакетов меня не устраивает по определению.
Gentoo, вообще-то, рассчитан на автоматическую сборку, а не на ручную. Gentoo это тот же Debian + как бонус возможность безгимморойного выбора зависимостей. Например, если не нужна поддержка GNOME в пакетах, просто, в одном месте прописывается USE флаг "-gnome" и все пакеты собираются без GNOME. Вс╦ делается автоматически. Никакого ковыряния руками.

Ну, мне время нужно было, я не на работе, а на отдыхе в Париже, не торопись с выводами.
> Например, тем, что он привязан к Debian, а дебиан (фактически) мёртв.
Нет. Есть testing ветка где практически глюков нет и софт не совсем старый и есть unstable ветка, где софт самый свежий, но не оттестированна совместимость с другими пакетами. stable ветка это надёжная оттестированная ветка. Но софт в ней староват всегда, но не потому что Debian мёртв, а потому что процесс медленно происходит.
> Ещё раз напомню - дистр _не должен_ быть расчитан на то, что сборка будет происходить вручную.
Это всеобщее заблуждение тех, кто почему-то полагает, что надо смотреть на то, как пакеты автоматически собираютя и ставятся, либо тех, кто верит в то, что ничего делать в это время нельзя.

Че это ты такой агрессивный сегодня? Фф не грузиццо? :-D

На примере rtorrent: даже unstable реально отстает от Gentoo :(

Вы хоть сами понимаете что пишите?
Вполне. Дистрибутив, который не обновляется в _полном_ объеме _непрерывно_ - м╦ртв. Только не надо рассказывать про самоотверженный труд фанатов GNU - поверьте, те, кому платят, этот самый труд выполняют лучше и чаще, а не в промежутках между митингам в пользу FSF.
Если человек не хочет слышать, то он и не услышыт.
Может быть, Вы ткнете меня носом, где ответ на мой вопрос? Я получил кучу советов поставить то или это (без существенной аргументации, заметьте), вплоть до попыток убедить меня в том, что RPM это гадость - но ответа на вопрос не получил. Знаете, я с линухом весьма не поверхностно знаком с 1993 года, и прекрасно себе представляю, что есть что. Вы же скатываетесь на личные пристрастия.

Да нет, с фф фс╦ пучком, 2.0 рул╦з =) Просто человек абсолютно не ориентируясь в вопросе, говорит глупости. Оказывается проблема deb/dpkg/apt/ в том, что это привязано к Дебиану, а он видете-ли умирает. Жесть =D

RPM по сути это средство для сборки/установки/получении информации одиночного пакета.
Ах... Вот ты про что. Но ведь есть yum, в конце концов :)
Ммм, а как, например, "патчами и etc" происходит процесс обновления Glibc? Проблем не возникает?
Не-а. Пока не было.
в одном месте прописывается USE флаг "-gnome" и все пакеты собираются без GNOME. Вс╦ делается автоматически.
А "прописывается флаг" тоже автоматически? :) gentoo это набор "сделай сам", по сути. Пусть даже и с роботизированной сборкой с ЧПУ :)
но не потому что Debian м╦ртв, а потому что процесс медленно происходит.
Это и есть "м╦ртв" в мо╦м понимании. Время реакции в месяцы меня не устраивает. Жив - это время реакции менее недели. Ну а про фанатизм я уже сказал - если люди критерием построения дистра считают соответствие лицензии стандартам GNU, а не функциональности и полезности - это не для меня.
Это всеобщее заблуждение тех, кто почему-то полагает, что надо смотреть на то, как пакеты автоматически собираютя и ставятся, либо тех, кто верит в то, что ничего делать в это время нельзя.
Ээээ... Поясню - я имел в виду, что не хочу _сам_ отслеживать изменения, патчи и advisories для апдейта пакетов. Разумеется, я в курсе, что я могу чем-то ещ╦ заниматься в процессе сборки и установки - я просто не хочу делать эту сборку и установку _сам_ - это работа для авторов дистра Времена, когда я копался в ядре и прочих сорсах ради интереса - давно прошли, да и времени у меня сейчас на это нет.

> Может быть, Вы ткнете меня носом, где ответ на мой вопрос?
http://foren.germany.ru/linux/t/6219303.html?Cat=&page=0&view=collapsed&sb=5&vc=...
http://foren.germany.ru/linux/t/6220035.html?Cat=&page=0&view=collapsed&sb=5&vc=...
Ручками сделать выбор пакетов не судьба? Если у Вас *оссобенные* запросы как по ядру так и по всей системе в целом, будте готовы к тому что многое прид╦тся делать самому.
> Дистрибутив, который не обновляется в _полном_ объеме _непрерывно_ - м╦ртв.
- 1e это Вы так решили что Деб не обновляется, или Вам об этом кто-то рассказал.
- 2е deb/dpkg/apt развиваеться не только командой Дебиана. (это так, маленькая подсказка)

> А "прописывается флаг" тоже автоматически?
Так это делается один раз и занимает полминуты времени.
> эээ... Поясню - я имел в виду, что не хочу _сам_ отслеживать изменения, патчи и advisories для апдейта пакетов.
Так это, зачем самому-то отслеживать? emerge --sync; emerge --uD world и всё. Ни за чем следить не надо.
Я пока не сделал, но народ пишет, что в крон засунуты вызовы обновления дерева пакетов и безопасногое обновления системы, и приходя на работу человек имеет либо вчерашнее, либо самое свежее и новое, если всё прошло без проблем, вообще без всяких телодвижений.

Ручками сделать выбор пакетов не судьба?
Я уже говорил - это не помогает. Попытка удалить очевидно ненужные вещи приводит к тому, что деинсталлируется почти вс╦ остальное (и нужное). Пример с pcre я уже приводил.
будте готовы к тому что многое прид╦тся делать самому
Вопрос был, _есть_ ли _готовая_ система, а не "как сделать" - почувствуйте разницу. Как сделать самому я прекрасно в курсе, но это как раз то, чего делать не хочется.
1e это Вы так решили что Деб не обновляется, или Вам об этом кто-то рассказал.
Простой пример (только что залез): ipsec-tools (1:0.5.2-1sarge1) - если это stable и текущий - повесьте меня. Именно с этой версией у меня были проблемы в сво╦ время (грубо говоря, оно было несовместимо с текущим стеком в Cisco и некоторых других). Второй пример: openssh-server-udeb (1:3.8.1p1-8.sarge.4) - это разве похоже на 3.9? Или мне мерещится? Я уже сказал в начале - мне нужен _современный_ дистр. По остальным пакетам такая же история. Знаете-ли, я не разделяю точку зрения на "stable", которая существует у дебиановцев, особенно когда то, что они называют stable, однозначно не stable.
2е deb/dpkg/apt развиваеться не только командой Дебиана
Ну назовите несколько дистров, удовлетворяющих условиям тонкости и современности, использующими dpkg/apt, и не сопровождаемые консерваторами а-ля дебиан.

Вывод очевиден.

Вы принципиально не вникаете в то что Вам пишут? Повторяю, ставте вето "с риском нестабильности" на то что Вам не нужно и вперёд.

Нет, похоже Вы принципиально не читаете то, что Вам пишут, так как это наверно расходиться с Вашим мнением. Повторяться не буду перечитайте ещё раз пост voxel3d о ветках Дебиана - stable, testing, unstable.

Пустой звук и не более.

Ubuntu - есть возражения?

Вы решите для начала, либо современный либо стабильный.
---
А у вас модем ночью не храпит?

http://de.wikipedia.org/wiki/Fedora_Core может тебе подойти. базируется на RPM, зависимости проверяются при помощи YUM. наследник RH, а он вроде не плох.
сам не работал но у нас в уни его частенько используют унивеские работники как вторую систему рядом с виндой. те кто винду не любят из различных соображений не любят и федору и используют дебиан или солярис, это в основном геофизики, информатики порой мамтематики. на всех компах от уни стоят винда и сузя. видать ее легче понять юзверям, но админов мне жалко...
а вобще тебе не нужен другой дистр. пользуйся себе зузей. а если зузю настроить не можешь то в других дистрах тебе делать нечего. имхо. это лишь показывает ненужность пользовать линух. тем более что ты в винде хорошо разбираешся и все время утверждаешь что она удовлетворяет твои потребности. как там было "Never change a running system ..." так что смотри стоит ли игра свечь!

knopixx

Ты как обычно пальцем в небо :-P Читай всю тему перед тем, как ответить.

читаю вот, но понимаю что не нужно ему это все :-P

> О том, что тупая компиляция и установка пакета иногда приводит к проблемам в уже работающей системе - из-за несовместимости изменений в новых версиях со старыми версиями.
Тои же самое случается и при установке рпм. Нечасто, но случается.
> Или берут готовое, с патчами, которое удовлетворяет требованиям, и за которым следят (RH/SuSE).
Мне хватило гцц 2.96. Клуб "очумелые ручки".
Чесно говоя, вы мне напоминаете блондинку, которая хочет туфельки, которые внутри больше чем снаружи.
---
Hе все то мышца, что pастет на теле.

Повторяю, ставте вето "с риском нестабильности" на то что Вам не нужно и впер╦д.
Скажите, Вы мазохист? :) Я лично не люблю систем, которые представляют из себя карточные домики, не говоря уже о том, что предложенный Вами метод хорош для одной инсталляции, а не десятка.
перечитайте ещ╦ раз пост voxel3d о ветках Дебиана - stable, testing, unstable.
OK, ещ╦ раз скажу - открытым текстом. У меня _нет_ доверия к людям, которые вставляют в stable ветку однозначно unstable пакеты. Так моя точка зрения понятней? По этой причине меня остальные ветки уже не интересуют.
Ubuntu - есть возражения?
Сейчас попробуйю поставить минимальную систему и посмотрю, в ч╦м его принципиальное отличие от дебиана Если инсталляция займет более 300M (даже после чистки) и будет содержать пакеты старше 1 года - я сделаю соотвествующие выводы. Только не надо опять про testing & unstable ветки - Вы ведь не будете ездить на авто, который не испытан и не подлежит сервису, правда?

Вы решите для начала, либо современный либо стабильный.
Современный стабильный Есть вещи, которые просто нестабильны в несовременном виде (пример с ipsec я уже приводил).
Да, я понимаю, что хочу странного, но почему бы и не хотеть? А уж если не получится... Тогда будем думать.

Мммдааа..... ну и прич╦м тут это? Если сообщение пугает ламера, что в результате реализации его взглядов на систему она будет нестабильна, это ещ╦ далеко не означает, что так будет на самом деле. При условии что ты ч╦тко представляешь себе что ты делаешь и зачем. Слышать такое от человека который до этого утверждал Как сделать самому я прекрасно в курсе и ж╦стко критиковал майнтейнеров - просто смешно.

Угу, только апгрейд после инстала сделать не забудь.

Если сообщение пугает ламера, что в результате реализации его взглядов на систему она будет нестабильна, это ещ╦ далеко не означает, что так будет на самом деле. При условии что ты ч╦тко представляешь себе что ты делаешь и зачем.
Я в курсе. Но увы, я не знаю _тонкостей_ построения ни SuSE, ни RH-based систем. Допустим, я мог удалить pcre, начихав не предупреждения, как и многое другое, сравнительно безопасно - но я бы столкнулся с другой проблемой - каждая последующая попытка обновить такую покореженную систему вызывала бы вопли о нарушенных зависимостях. Да, вс╦ это можно игнорировать, до поры - но это уже начало того, что называется inconsistence... Чего я хочу избежать тоже. Посему и искал систему, где вс╦ грамотно распланировано изначально.
Угу, только апгрейд после инстала сделать не забудь.
Не набуду. Правда, мне всегда было интересно, что делать тем, у кого закрытые (т.е. без доступа извне) инсталляции. Как просто держать текущий дистр, с последними обновлениями... А-ля сервис-пак... Что бы бравший его точно знал, что там все апдейты на момент скачивания...

Итог установки ubuntu в минимальном варианте (LAMP) - 500M. Н-да. Плюс отсутствие set/get-facl и ещ╦ ряда полезных пакетов... Сказывается, видимо, дешевизна жестких дисков... "Вопросов больше не имею" - как сказал бы сын турецко-подданного...

500M - Жесть! Завидую я как вы сервера ставите =D Вы в ответ на приглашение инсталлятора просто enter нажали? =) Ну и какие ещё могут быть вопросы? Просили *комплексный обед*? - Вы его получили. Видимо прочитать что-нибуть перед инсталляцией и поставить сервер в режиме эксперта - не барское дело =)))

Ээээ... Как наивный человек, я ожидал, что LAMP поставит необходимый _минимум_. Только не надо меня убеждать, что все необходимые компоненты LAMP занимают не менее 500M. Или, по Вашему, LAMP - это и есть комплексный обед, а? Хотя да, в какой-то мере, но не в таких же размерах...
Но так уж и быть, как и положено, я выбираю опцию установки в режиме эксперта... И что я получаю? После установки _базовой_ системы (до не╦ возможности выбрать что-либо не предлагают, впрочем, после тоже) уже использовано 330M. Ээээ... Я-то, дурак, думал что "базовая" - это система с ядром, шеллом и менеджером пакетов, ну с редактором текстовых файлов... То есть абсолютный минимум, который можно накрутить как угодно... Ну зачем мне навороченная версия vim в _базовой_ системе? Зачем мне питон в той же базовой системе, а? И, честно говоря, мне лень смотреть, куда ушло аж 300 с гаком мег на "базовую" систему...
Заметьте, это вс╦ в Вашем любимом "режиме эксперта" - никаких вопросов. Или я слепой, или я не вижу где там выбрать пакеты - в инсталлере (да-да, в режиме эксперта) есть только опция "Select and install software", при нажатии на которую что-то происходит, в результате размер инсталляции увеличивается до 500M, но вопросов по прежнем не задают. Единственный выбор мне был предоставлен, когда речь шла о модулях для железа. Видимо, настоящие эксперты не должны заморачиваться ничем, кроме модулей к ядру...
Ну что, доктор? Прокомментируете? Вы его сами-то ставили, а?

Я ни в ч╦м не собираюсь Вас убеждать, хочу сказать только одно: Когда Вы начн╦те полагаться на описания, а не предположения, результат будет более предсказуемый.

Это я коментировать не буду.

Я могу собрать Ubuntu на max.100Мб. Base + X-сы + GUI + рабочий минимум софта. Мог-бы сбросить Вам ссцилу где это разж╦ванно по шагам, но только Вы ведь не любите *ручной труд*, а так-же читать документацию.
Ubuntu может быть очень даже "тонким", но для этого надо начинать с изучения доков.

Когда Вы начн╦те полагаться на описания, а не предположения, результат будет более предсказуемый.
Ээээ... Я точно _знаю_, что LAMP влезает в менее чем 100M, даже в навороченном варианте. Это не предположение, это _опыт_. Если создатели Ubuntu и других дистро считают, что не время экономить - что ж, наши пути разошлись.
но только Вы ведь не любите *ручной труд*
Вы только догадались? Я этого не скрывал и говорил с самого начала, собственно
Я не хочу ручного труда, потому и ищу что-то _готовое_ (в лучших традиция *ix - не изобретать колесо). В конце концов, если кто-то сделал knoppix, то могло случится также, что кто-то другой сделал mini-redhat... увы... Оказывается, попытка не изобретать сво╦ колесо приводит к тому, что готовое колесо оказывается квадратным и весит в 10 раз больше, чем нужно. Супер.
Ubuntu может быть очень даже "тонким", но для этого надо начинать с изучения доков.
Знаете, и козла можно научить говорить, если очень захочется. То что это можно сделать, сомнений нет, мне даже документации не понадобится, пару часов времени хватит, я думаю. Но, Вашими же словами - Вы ведь не читаете... Я не спрашивал "можно ли" и "как сделать" - я спрашивал "есть ли готовое"

> Я точно _знаю_, что LAMP влезает в менее чем 100M
- Ну оно и заметно.
> Если создатели Ubuntu и других дистро считают, что не время экономить - что ж, наши пути разошлись.
> то могло случится также, что кто-то другой сделал mini-redhat... увы... Оказывается, попытка не изобретать сво╦ колесо приводит к тому, что готовое колесо оказывается квадратным и весит в 10 раз больше, чем нужно. Супер.
- Старая пестня о нерадивых дистростроителях, среди которых не нашлось ни одного, который проникся-бы Вашими идеями по поводу концепта идеальной системы?
Перепроверил и вс╦-же отвечу на это =) >куда ушло аж 300 с гаком мег на "базовую" систему...
То что Вы там описывали выше, а именно базовая система, это округл╦нно в плюс - 52+1+40+40+40 итого - 173 Откуда у вас 300 - Вам видней -)

Старая пестня о нерадивых дистростроителях
Ладно, так и быть - назов╦м их дистростроителями 21 века, у которых не бывает HDD меньше чем 250G, на фоне которого лишние 500M-1G просто незаметны. Так будет лучше? :) Собсно, я уже сказал, что мне не особо важно место, мне важно то, что там много лишнего, и мне не хочется его убирать ручками.
Откуда у вас 300 - Вам видней
Результат df после окончания фазы "Install base system" (свежевытащенный Ubuntu Server CD 6.06.1), однако. В отличие от Вас, я больше верю не документации, а своим глазам :) Хорошо, допустим что там кэш и временные файлы etc. Но даже 173M это очень много для _базовой_ системы, даже для LAMP (хоть Вы и сомневаетесь). Что я понимаю под термином "базовая" - я говорил выше.
Ну а если вернуться к Вашим любимым руководствам - то да по их собственным минимальным требованиям, необходимо 500M дискового пространства, для серверной системы. Это уже говорит о том, что система не расчитана на "тонкие" инсталляции (заметьте, я не утверждаю, что это невозможно сделать - я лишь говорю, что она "не расчитана" в дефолтном варианте).
Впрочем, какой смысл спорить, а? Вопрос отвечен в духе "не бывает", можно закрыть дискуссию, я думаю...

Есть такой дистрибутифчик :)
KANOTIX
Условиям отвечает... тонкий и современный , ядро последнее , кде (по дефолту) последнее , alsa последняя, поддержка железа - впечатляет, набор софта по умолчанию ... больше чем надо, локаль - немецкая, английская, французкая (прикрутить можно хоть молдавскую) , есть куча примочек именно от Kanotix : морда для конфигурации х-сервера, морда для удаления /добавления сервисов при старте и еще много чего , в sources.list есть репозитарии дебьяна (никто не мешает поубирать диезы ### возле строчек unstable, есть и собственно kanotix . Можно использовать как live CD , но имеется и интуитивно понятный графический инсталятор .
Все что я лично добавила после инсталяции : подправила шрифты , добавила репозитарии с аудио / видео кодеками , репозитарий vlc и вроде бы все.

Знаете, Вам нужно сюда http://distrowatch.com/search.php не буду выкладывать что выдал поиск по Вашим условиям, server, rpm, i686. Попробуйте сами, если найд╦те то, "чем сердце успокоиться" - сообщите, очень любопытно

Увы... Поиск показал, что то, чего я ищу, уже не существует. То есть, существовало в 2004-2005 гг (проекты типа Basilisk), а потом все подобные проекты были заброшены - видимо, в связи с тем, что цены на HDD и RAM резко упали. А идея выбросить вс╦ лишнее по причине того, что оно просто лишнее (а не в связи с нехваткой ресурсов) либо никого не интересует, либо никому не пришла в голову - кроме авторов проектов типа "рутер на дискете".
Жаль, жаль... Прид╦тся жить с тем, что есть...
Всем спасибо за участие

> А идея выбросить вс╦ лишнее по причине того, что оно просто лишнее (а не в связи с нехваткой ресурсов) либо никого не интересует, либо никому не пришла в голову - кроме авторов проектов типа "рутер на дискете".
Как это, не пришла? В треде называли дистрибутивы, а то, что ты не хочешь, например, с Gentoo связываться не означает, что он не удовлетворяет названным критериям. Я не могу оценить, насколько, на самом деле, стабильный Debian "небезопасный", но сда╦тся мне, что кривых пакетов еденицы и проапгрейдить их до стабильных версий пл╦вое дело, особенно, когда ты знаешь, что для тебя в системе критично. Ты как капризный реб╦нок - то не нравится, с╦ не нравится и, я думаю, ты просто сам не знаешь, что тебе надо. Там где нужна мегастабильность, обновление софта, кроме апдейтов безопасности, нафиг не упиралось, а если охота со свежим софтом играть, то на рабочем сервере это не делают и, соответственно некоторые ляпы простительны.

а то, что ты не хочешь, например, с Gentoo связываться не означает, что он не удовлетворяет названным критериям
Там нет менеджера пакетов в нормальном виде. Не существует _автоматического_ способа просчитать зависимости пакета, который существует только в виде исходников. К тому же, я уже говорил, это плохая идея - компилировать пакеты каждый раз, когда они нужны, вместо того что бы поставить готовый бинарник. На серверах не должно быть вообще компиляторов, если уж на то пошло - они там нафиг не сдались.
но сда╦тся мне, что кривых пакетов еденицы и проапгрейдить их до стабильных версий пл╦вое дело
Угу, пл╦вое. Но я уже объяснял - после этого пл╦вого дела мне прид╦тся самому следить за замененными пакетами (текущие security патчи etc), а если инсталляций больше чем одна - то на всех из них. Как раз то, чего мне делать не хочется, ибо мне есть чем заняться - времена моего сисадминства канули в лету около 10 лет назад.
я думаю, ты просто сам не знаешь, что тебе надо
Знаю прекрасно. Хочу нормальный дистр с нормальным менеджеров пакетов, managed (т.е. где регулярные обновления как минимум по security), где все зависимости отточены (во время сегодняшних экспериментов, например, столкнулся с тем, что установка MySQL сервера тянет за собой DBD-MySQL - совершенно непонятно, чем думал строитель пакета, ведь второе зависит от первого, а не наоборот), где ничего лишнего нет, и где _базовая_ система не требует 300M.
а если охота со свежим софтом играть, то на рабочем сервере это не делают
Да ну? Например, Postgres 8.1 - это достаточно свежий софт, и при этом достаточно стабильный, но пойди найди его в последней CentOS, например... Прич╦м, некоторые приложения как раз требуют версии не ниже 8.0. Я мог бы привести много примеров, но скажу кратко - "свежий" это значит "текущий стабильный", а не "прошлого года" (если учесть что уже конец года, и была пара релизов в промежутке).
Кстати, "старый" не всегда синоним "стабильный" (про ipsec-utils я уже говорил - яркий пример). Дистрибуцию называют стабильной, если не получили много нареканий в процессе тестов, а их отсутствие скорее говорит о низкой интенсивности тестов, чем о качестве. В системе несколько тысяч пакетов, реально из них _используется_ в лучшем случае несколько десятков - соответственно и "тестированием" это можно назвать с натяжкой...

Глупости, прежде чем такое утверждать, прочтите что-нибуть о APT/dpkg, хотя-бы <APT mini-HOWTO>.

Что глупости? Что мне самому прид╦тся следить за мной же установленными пакетами? Или apt/dpkg будет сам тащить новые версии, применять патчи, компилить и ставить вместо меня, решать проблемы которые могут при этом возникнуть? При условии, разумеется, что этот пакет не часть дистрибуции. Если этого не делают авторы дистра или кто-то ещ╦ (а компиляция и установка своих пакетов как раз предполагает, что никто другой этого не делает) - то это прид╦тся делать мне, или я настолько отстал от жизни и APT/dpkg представляют навороченный AI, заменяющий сисадмина? Да, я могу автоматизировать установку и обновление на нескольких хостах, но следить за текущестью вс╦-таки прид╦тся.
В конце концов, зачем придумали дистрибутивы и их строителей? Что бы пользователи (пусть даже и продвинутые) сами вс╦ ставили, ручками? А работать когда?

Не надо путать теплое с мягким. Полагаетесь на дистростроителей - используйте автоматическое обновление. Ставите что-то свое - несите ответственость за свои действия. У всех дистрибутивов своя политика и похоже ни одна вас не удовлетворяет. Тогда делайте сами. Глупо предьявлять претензии людям, которые вам ничего не должны.
---
В оптический пpицел мы смотpим с оптимизмом!

Вы с матерьялом ознакомились? Тяжело спорить о вкусе устриц с человеком, который их не ел.

Да.
----

Да. ***И не высасывайте сложности из пальца, там где их нет.
----

Нет. ***.
----

Незнаю. Учите матчасть, прежде чем начинать спорить.
----

С этим вопросом в ДК, там такие темы *за мир во вс╦м мире* любят.

Глупо предьявлять претензии людям, которые вам ничего не должны.
Я никому ничего не предъявлял. Я всего лишь спросил, есть ли что-то готовое, удовлетворяющее моим требованиям, что бы мне самому ничего не пришлось делать. Да, я высказался в духе "хреново они работают, раз нет" - но это не претензия, а (если можно так сказать) "риторическая жалоба". Вот и вс╦. Меня же завалили советами на тему "можно взять апельсин, срезать с него шкурку, покрасить - и получится яблоко"

Учите матчасть, прежде чем начинать спорить.
Да ну? Ну расскажите мне способ, которым APT/dpkg способен _сам_ взять новую версию чего-то (в исходном виде), применить патч, откомпилить, обнаружить что нехватает какой-то либы (или хидера), взять то чего не хватает, попытаться его скомпилить или поставить (с риском напороться на аналгичную проблему), повторять процесс до победного конца, в финале выдавая готовый к дистрибуции пакет. Увы, мне такое чудо природы найти не удалось - все _проблемы_ возникающие при компиляции решаются только ручками, и APT/dpkg их не решает.
Даже если предположить, что я пропишу где что брать и что с ним делать - вопрос решения потенциальных проблем остается открытым, и в итоге, если таковые возникнут (а они возникнут, это только вопрос времени), решать их прид╦тся мне самому - как раз то чего я делать не хочу (сколько раз мне про это нужно сказать, что бы не получать советов "сделай ручками" и "вс╦ решается при желании"?).
Так что давайте не будем про матчасть - AI, способный заменить человека в рассматриваемом случае, ещ╦ не создан, иначе бы у меня не было проблемы, в связи с которой я задал вопрос.

Винегрет из набора фраз на тему. Сформулируйте ч╦тко что Вы хотите, тогда я расскажу как это сделать.
----

Облость предположений меня мало интересует.
----

Только так и никак иначе, нравиться Вам это или нет.
----

Вам здесь уже ни раз сказали в ч╦м Ваша проблема.

Вы забыли включить злобных инопланетян и происки Ктулху.
---
Внебрючные отношения.

> Там нет менеджера пакетов в нормальном виде.
Ага, как же, нет, с чего ты взял? Система называется portage.
> Не существует _автоматического_ способа просчитать зависимости пакета, который существует только в виде исходников.
Пакета или программы? Если говорить о программах, то для собственных программ это не нужно, а если о тех, что существуют в природе для Linux, они все есть в дереве портежей в виде пакетов. Portage позволяет посчитать зависимости пакетов _автоматически_.
> К тому же, я уже говорил, это плохая идея - компилировать пакеты каждый раз, когда они нужны, вместо того что бы поставить готовый бинарник.
Portage позволяет работать и с бинарными пакетами. Только это никому не нужно, кроме случая, когда пакеты собираются сразу для всей сетки на одном компьютере. Насч╦т "плохой идеи": барин - хозяин, но, в любом случае, обновление софта полностью подда╦тся автоматизации и может проходить полностью без участия человека.
> где все зависимости отточены
Чудной человек - вон, в Слаке ихний рулевой "отточил" зависимости от Гнома. Теперь проблемы с Гномом там нет как класса. Как и самого Гнома. Нафиг надо, такие отточенные зависимости - вот, скажи, с чем линковать mc, к примеру, с ncurses или с slang должны дистростроители твоего гипотетического дистрибутива? (обе библиотеки для консольной отрисовки умеет использовать mc).
>> а если охота со свежим софтом играть, то на рабочем сервере это не делают
>Да ну?
Ну да. Это для тебя новость? Хочешь поиграть с одной занимательной программой длинной в одну строчку на Perl- е на сво╦м сервере?
Там где _работают_ любое изменение окружения проходит крайне консервативно. И предварительно тесты проводят на тестовой машине, чтобы не угробить рабочую систему, если что-то пойд╦т не так, и причина всегда должна иметься, чтобы что-то менять, а не просто от балды в виду выхода новой версии. Все пионерские подвиги с тестированием новых версий программ на рабочих машинах оканчиваются обычно увольнением. Если контора, конечно нормальная, а не шаражка какая.
Как ты думаешь, почему ещ╦ живо ядро ветки 2.4.хх, ведь, есть же более архитектурно правильная ветка 2.6.xx? Или почему PHP5 нифига не рулит до сих пор, а везде стоит PHP4, который просто издевательство над программистом? Или почему жива первая ветка Apache?

> Да ну? Ну расскажите мне способ, которым APT/dpkg способен _сам_ взять новую версию чего-то (в исходном виде), применить патч, откомпилить, обнаружить что нехватает какой-то либы (или хидера), взять то чего не хватает, попытаться его скомпилить или поставить (с риском напороться на аналгичную проблему), повторять процесс до победного конца, в финале выдавая готовый к дистрибуции пакет. Увы, мне такое чудо природы найти не удалось - все _проблемы_ возникающие при компиляции решаются только ручками, и APT/dpkg их не решает.
А оно не надо. Если надо безгимморойно собрать программу, при отсутствии нужных зависимостей, есть auto-apt:
auto-apt run ./configurе
всё необходимое для сборки автоматически доставится. Ну, а потом checkinstall какой-нибудь, который делает пакеты.

Сформулируйте ч╦тко что Вы хотите, тогда я расскажу как это сделать.
OK, попытка номер... эээ... большой. Есть система с кучей пакетов, многие из которые или устарели, или не содежат того что нужно, а многие просто лишние. При этом, система построена на PM (неважно, RPM или DPKG или хз что ещ╦), то есть просто заменит/удалить нужное/ненужное приводит к развалу и шатанию (с точки зрения PM). Задача: Имея такую систему, удалить вс╦ ненужное, но так, что бы PM не считал это нужным (а он это делает). Заменить ряд пакетов новыми (современными) версиями и поддерживать их в текущем виде (security etc), опять-таки, не нарушая спокойной жизни PM, если добавится что-то, не знающее о новой версии. Размножить это вс╦ на N компов. Ну и самое главное - это вс╦ должно занимать не более 15 минут в неделю, желательно без участия человека вообще. Особые условия: Gentoo/Debian/Ubuntu/Slackware не подходят по идейным (необсуждаемым) соображениям.
Вам здесь уже ни раз сказали в ч╦м Ваша проблема.
Да-да, я знаю - моя проблема в том, что я родился

Вы забыли включить злобных инопланетян и происки Ктулху.
Не-а. Я забыл, какого хрена хорошо известный djb по прежнему не включает <errno.h> в своих (весьма полезных, кстати, тулзах), в то время как это необходимо во всех современных дистрах линуха (иначе не работает, т.е. не компилируется или не собирается). Это похлеще инопланетян будет... А казалось бы - мелочь, да...

Если говорить о программах, то для собственных программ это не нужно, а если о тех, что существуют в природе для Linux, они все есть в дереве портежей в виде пакетов. Portage позволяет посчитать зависимости пакетов _автоматически_.
А чем собственные программы отличаются от несобственных, а? С этой точки зрения? У них тоже бывают зависимости А вот как portage _сам_ посчитает зависимости, имея исходники ранее _неизвестного_ приложения - это для меня тайна, покрытая мраком. Иногда даже ручками (глазками) это тяжко сделать. Не говоря уже о случаях, когда зависимости могут быть обязательными, а могут быть опциональными.
Portage позволяет работать и с бинарными пакетами. Только это никому не нужно, кроме случая, когда пакеты собираются сразу для всей сетки на одном компьютере.
"никому"? Это нужно всем, кто не хочет заморачиваться с компиляцией всего из исходников. Какой в этом смысл? Особенно когда речь про сетку.
обновление софта полностью подда╦тся автоматизации и может проходить полностью без участия человека
Ну-ну... Зависит от софта... Иногда новый софт _слегка_ несовместим со старым, или с чем-то ещ╦, в общем, вс╦ зависит. Автоматизации легко (сравнительно) поддается только обновление, которое было приготовлено кем-то извне, и то, бывают проблемы (например, когда "новой" версией заменяется установленный вручную пакет, той же версии но с другими опциями скомпилированный - и вс╦ ид╦т нафиг).
Чудной человек - вон, в Слаке ихний рулевой "отточил" зависимости от Гнома. Теперь проблемы с Гномом там нет как класса. Как и самого Гнома.
Это наш человек Ибо гном мастдай Ну зачем такой монстр нужен, а?
вот, скажи, с чем линковать mc, к примеру, с ncurses или с slang должны дистростроители твоего гипотетического дистрибутива?
Я бы предпочел две версии, если честно Хотя, с учетом размера slang, я бы не возражал против только одной. Но в мо╦м гипотетическом дистрибутиве пакеты бы требовали то, чего им не нужно для работы, и не ругались на опциональные компоненты (типа поддержки TTF в случае установки PHP).
Хочешь поиграть с одной занимательной программой длинной в одну строчку на Perl- е на сво╦м сервере?
Со мной такие штучки не проходят А чайники смело вводят даже "rm -rf / &". Но я говорил не про эксперименты такого типа, а про _работающие_ и _проверенные_ вещи, просто новые (примеры см. раньше).
Там где _работают_ любое изменение окружения проходит крайне консервативно.
Спасибо, я в курсе. Я и не говорю об изменениях - я говорю об установке _современного_ софта, и его использовании, а не смене пакетов с разной major version на живой системе.
Как ты думаешь, почему ещ╦ живо ядро ветки 2.4.хх, ведь, есть же более архитектурно правильная ветка 2.6.xx?
Потому что некоторые свято верят, что оно стабильней и надежней, чем 2.6 (совершенно зря - это верно только в частных случаях). Но в большинстве приложений эта разница неощутима, а некоторым нужны как раз фичи из 2.6, при этом оно вполне стабильно. И PHP5 вполне рулит, просто под него мало приложений, и он частично несовместим (не на уровне стабильности) с PHP4. Первый же апач жив условно - его мало кто использует. Но если поискать - то можно найти консерваторов, у которых ещ╦ стоит ядро 1.2, Perl 4 etc :)

понимаешь какая штучка выходит! дело в том что таких дистрибутивов не существовало и существовать не будет.

из этого всего хотелось бы подчеркнуть что в твоей формулировке присутствуют эллементы выражающие ТВОИ желания и просимулировать их не представляется возможным, потому как сначала необходимо знать чего тебе хочется. это еще пол-беды выразить, что тебе необходимо. вся беда заключается в том как это передать системе.
без рукоприкладства здесь никак не обойтись и я вижу всего лишь 3 варианта в твоей ситуации:
1. взять простенький попсовый дистрибутивчик типа канотикса или убунту и настроить его после установки под себя
2. взять по сложнее дистрибутивчик типа генту, слаки и настроить как тебе это нужно.
3. построить дистрибутивчик самому на основе LFS http://www.linuxfromscratch.org/. один раз настроил ВСЕ как тебе нужно, ВКЛЮЧАЯ пакетменеджмент и про все забыл.
но если посмотреть в общем и целом то время рукоприкладства везде одинаково просто распределяется по разному и выражается в раззной форме.
советую конкретно сформулировать проблему и расписать ее по пунктам а после смотреть что из существующего тебе подходит.
удачи в поиске!

то еще пол-беды выразить, что тебе необходимо. вся беда заключается в том как это передать системе.
Ещ╦ раз повторюсь - я знаю как это передать и сделать, я просто _не хочу_ этого делать. Я надеялся, что кто-то это уже сделал за меня - напрасно, как оказалось.
советую конкретно сформулировать проблему и расписать ее по пунктам а после смотреть что из существующего тебе подходит.
Если из моих требований убрать занимаемое пространство и не всегда понятные зависимости - то мне подходит Fedora Core. Видимо, на этом и остановлюсь... Из всего спектра обсужденных дистров мне вс╦-таки (с административной и прикладной точки зрения) ближе RH-like системы.
Хотя в свое время я был фанатом Slackware и так же рьяно отстаивал точку зрения, что вс╦ нужно делать ручками... И не понимал тех, кто не хотел или не умел этого делать... Точно также не воспринимал их аргументы... А потом я вырос

> А чем собственные программы отличаются от несобственных, а? С этой точки зрения?
Ну, это же просто: для работы на данном компе собственной программы написанной тут же, ничего доставлять не надо, вс╦ уже есть (в процессе написания программы было поставлено).
> А вот как portage _сам_ посчитает зависимости, имея исходники ранее _неизвестного_ приложения - это для меня тайна, покрытая мраком.
Portage не знаю пока, не интересовался в силу ненадобности, есть ли что-то подобное auto-apt и что вообще есть в области автоматической генерации ебилдов (файлов в которых расписано вс╦ о пакете) - поинтересуюсь сегодня, про APT же я написал выше.
> Ну зачем такой монстр нужен, а?
Мне лично Гном не нравится этим же самым, но, это не мой подход - решать за пользователя, что ему нужнее. Я за свободу выбора.
> "никому"? Это нужно всем, кто не хочет заморачиваться с компиляцией всего из исходников. Какой в этом смысл? Особенно когда речь про сетку.
Я имел в виду пользователей Gentoo. Хотел сказать только, что только в тех наиредчайших случаях, когда Gentoo используют в сетке, пользуются распространением пакетов в бинарном виде после сборки их на одном компе.
> и то, бывают проблемы (например, когда "новой" версией заменяется установленный вручную пакет, той же версии но с другими опциями скомпилированный - и вс╦ ид╦т нафиг).
Ну, кто же вручную пакеты ставит? Это путь к хаосу и Слаке. Нафиг-нафиг. Всегда пакет сначала изготовить. Вот, кстати, yum не умеет маскировать, насколько я понял, пакеты от нежелательного апдейта. В Portage же, помимо маскирования, можно персоналльно для конкретных пакетов указать USE флаги.
> Но если поискать - то можно найти консерваторов, у которых ещ╦ стоит ядро 1.2, Perl 4
Когда система на 100% выполняет свои функциональные обязанности, изменять е╦ смысла нет.

да хотя бы федора ... мне лично тоже оч нравиться :)

Читал эту хохму как Патрик не асилил гном, честно говоря очень удивился.

В слацкваре уже давно не нужно делать ручками более того, что и в других дистрибутивах.
---
...Звеpей на эскалатоpе деpжите за клюв! (2:5020/423.39)

Просто была пара независимых проэктов, которые собирали гном для слаквари + дествительно жуткие зависимости внутри кучи гномьих библиотек. Все-таки он один работает над дистрибутивом. Вот и решил избавится от монстрика. К тому же с выходом 2.0 гном потерял довольно много приверженцев. Очень уж тормозным и неудобным он казался после 1.4.
---
Истиннyю ценy живого общения понимаешь, глядя на счета от пpовайдеpа.

Ну если один работает над дистром (не знал) то понятно. К примеру в убунте гном очень вылизанный, уже многими призна╦ться что гном в убунте лутший. Они как-то с самого начала выбрали его в качестве основного десктопа и видимо уже неплохо "набили руку" на н╦м. Т.е. это пример что если захотеть, довести до ума гном не проблема и было непонятно почему этого не смогли сделать в Слакваре. Но если он один работает, то вопросов нет.