Есть уже стандарты в Linux, которые возникли в процессе развития системы. В том числе и для "установки и управления приложениями с открытыми исходниками". Все должно идти естественным путем. Непонятное заявление. Нужно доводить до ума то, что есть.

Ну вот и хорошо. Появится наверно что то типа WISE :)

I really wonder why people trying to re-invent wheel, sorry, APT.

> Появится наверно что то типа WISE :)

No distro needs that shit.

P.S.

Sweet dream: APT for NT ...

Учитывая предидущую попытку стантартизации - Unitied Linux, которая была провалена, можно им только дать флаг в руки и мотор в задницу. ;-)

Ну, когда за тобой стоит компания с капитализацией в миллиард, может и получИтся...

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

Это еще один (или несколько) менеджер пакетов? Что-то вроде MSI & "Установка и удаление приложений" ? :)

А как будет совместимость с другими (уже существующими) системами/дистрибутивами ?

> Эти стандарты API призваны облегчить небольшим компаниям выпуск приложений для Linux.

Скорее всего, это вызовет новый виток "религиозных войн".

Ожидаем-то, ведь, от SUSE другое... а, именно, GroupWise... документооборот... А они опять в ту же трясину...

P.S. Что-то не радует...

Сдается мне Novell решила занять нишу linux десктопов для end-user-ов и развивать именно их, ибо:
1. Нишa enterprise linux занята Red Hat
2. Red Hat ушла с рынка десктопов

Если смотреть с этой точки зрения их шаг вполне логичен и обоснован. 

Короче могу поспорить - будет installer как на винде, и поставлятся будет видимо с зависимостями сразу :) или намертво привязанный к дефолтным либам

> Учитывая предидущую попытку стантартизации - Unitied Linux, которая была провалена, можно им только дать флаг в руки и мотор в задницу. ;-)

Почему провалена? Там все отлично. Один Red Hat не стал участвовать.

А Mandrake Soft , а другие ??? Тут ранее прозвучала здоровая мысль - всё должно идти само собой и всякие денежные мешки типа Novell не должны сюда лазить.

>> Есть уже стандарты в Linux, которые возникли в процессе развития системы

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

>> I really wonder why people trying to re-invent wheel, sorry, APT.

Such a wheel won't rolling on our 256k channel, which even shared with zounds of another users. So, apt sounds like m$'s "where do you want to go today" here. It seems, apt is useful thing in some cases but there are alot of situations where people will not moved far away using that. Also, what about storing the non-free soft into repository? :)

>> Это еще один (или несколько) менеджер пакетов?

Это было бы прикольно но не весело. ИМХО что реально нужно делать в этом направлении - _ЗНАЧИТЕЛЬНО_ изменить методику загрузки динамических библиотек.

>> Ожидаем-то, ведь, от SUSE другое... а, именно, GroupWise... документооборот...

Вполне может быть, что они ощутили некоторые проблемы при установке ПО с закрытыми исходниками на произвольную инсталляцию и решили сначала что-то как-то подправить.

Стандартизация и унификация это конечно хорошо.

Вопрос в том какого качества стандарты будут предложены и не даст ли это

возможности для разного рода грязных манипуляций.

Например они выпускают готовый софт стандарта В и говорят, что

В теперь заменяет А, у них продукт готов, а остальным придется

быстро бежать за паровозом.

Ага, Caldera/SCO Group тоже начали со "стандартизации Linux"... С учетом того что Caldera/SCO & Novell (которая и купила SuSE) это близнецы-братья, топ-менеджеры у них постоянно туда-сюда тусуются, боюсь что они Вам отстандартизуют - мало не покажется...:)

Один редхат, один мандрейк. Зато стал участвовать SCO. Вот это было полезное участие.

P.S. Теперь все пытаются догнать редхат.

RPM for NT == MSI

:))

Maxcom, этого всё ещё недостаточно, чтобы ввести принудительную регистрацию?

Мальчик, не спорь с Irsi,
он старый и хитрый :)

Caldera, действительно основана в 1994 г. Реем Ноорда,

бывшим Novell CEO.

а-по-барабану

> Such a wheel won't rolling on our 256k channel, which even shared with zounds of another users.

First of all, nothing prevents you from using APT with CD-ROM| ZIP drive | whatever. Second, problem you mentioned has nothing to do with methods of handling package dependencies. The way APT gets packages info is definitely not perfect and should be improved ( apt-rsync ?), but developing yet another package manager is (IMHO) a stupid idea.

> Also, what about storing the non-free soft into repository? :)

Why not? Repositories don't have to be public.

handling package dependencies is EVIL!!!!!!!!!!!!!!
Стандарта можно добиться только в рамках одного дистра, и даже в рамках
одного дистра история знает примеры, когда эти депенданси приводят к
неоправданному геморрою и работают далеко не так гладко, как их
рекламируют или как это "должно" быть в теории.

Нормальный новый package manager все равно придется писать, если есть
желание ввести по-настоящемуц единый стандарт. Нужно так же определить
минимальный круг общих динамических библиотек. Остальное собирать
статически. Нужно завести единую для всех базу с уникальным
проcтранством имен программ, живущих в /bin. Убрать нахрен /usr/bin.
Разную мегатонную хрень, типа KDE и Gnome бросать исключительно в /opt.
Все сервисы бросать исключительно в /service. Короче, работы очень и
очень много. APT - это приятная игрушка для детей. А нужно еще РАБОТАТЬ ;)

Нужно завести единую для всех базу с уникальным
проcтранством имен программ, живущих в /bin. Убрать нахрен /usr/bin.

Мдя. Матом я ругаться не буду, а сказать больше нечего.

>Убрать нахрен /usr/bin. >Разную мегатонную хрень, типа KDE и Gnome бросать исключительно в /opt.

могу, только поддержать всецело оратора... то что творится сейчас в /usr/bin после инсталляции системы "по умолчанию" (SuSe, ASP, RedHat) по своей "помоешности" сравнимо только наверное с /windows/system после года пользования. мне кажется это то чем страдала винда и теперь сильно страдает линух... неотделения того где лежит система и все остальное, что можно грубо говоря rm и все чисто... конечно во многом утрировано но я думаю идея понятна

>>Убрать нахрен /usr/bin. >Разную мегатонную хрень, типа KDE и Gnome бросать исключительно в /opt.

>могу, только поддержать всецело оратора... то что творится сейчас в /usr/bin после инсталляции системы "по умолчанию" (SuSe, ASP, RedHat) по своей "помоешности" сравнимо только наверное с /windows/system после года пользования. мне кажется это то чем страдала винда и теперь сильно страдает линух... неотделения того где лежит система и все остальное, что можно грубо говоря rm и все чисто... конечно во многом утрировано но я думаю идея понятна

А почему, собственно, /opt ? Есть же /usr/local, специально предназначенный для всего, что не относится к функционированию системы. Во фрюхе, кстати, так и сделано. Система ставится в / и /usr, а порты в /usr/local. Никакой помойки. В тоже время можно rm -rf /usr/local/* и система не перестанет работать. :-)

http://kde-look.org/content/preview.php?file=9134-1.png

> А почему, собственно, /opt ? Есть же /usr/local

А потому, что /opt и был придуман для крупных самостоятельных пакетов.
Читаем FSS:
/opt is reserved for the installation of add-on application software
packages.

A package to be installed in /opt shall locate its static files in a
separate /opt/<package> directory tree, where <package> is a name that
describes the software package.

А менять /usr/bin на /usr/local/bin - все равно, что менять шило на мыло. Хорошие кандидаты на /opt: kde, gnome, xfce, mozilla.

2 anonymous (*) (27.11.2003 18:31:03):

> handling package dependencies is EVIL!!!!!!!!!!!!!!

NOT handling package dependencies ( a la Windows -- "File C:\winnt\system32\blah-blah.dll already exists, overwrite?") is EVIL. Point.

> и даже в рамках одного дистра история знает примеры, когда эти депенданси приводят к неоправданному геморрою

Could you give any examples, please?

> и работают далеко не так гладко, как их рекламируют или как это "должно" быть в теории.

No program is bugless. One should fix bugs instead of not using it. > Нормальный новый package manager все равно придется писать, если есть желание ввести по-настоящемуц единый стандарт.

I think that's wrong. We need to define some set of policies ( a la Debian Policy ), but not to rewrite APT| dpkg

> Остальное собирать статически.

That's definitely bad idea. It makes [security] updates, bug fixing, etc terribly painful. One really NEEDS to resolve "dll hell" problem...

> Нужно завести единую для всех базу с уникальным проcтранством имен программ, живущих в /bin.

This staff seems to be defined by FHS.

> Убрать нахрен /usr/bin.

Could you explain please, WHY?

> Все сервисы бросать исключительно в /service.

That's wrong with /usr/sbin ?

> APT - это приятная игрушка для детей.

Have you ever used it?

2 anonymous (*) (27.11.2003 18:46:50):

> неотделения того где лежит система и все остальное,

What is "system"?

> что можно грубо говоря rm и все чисто

apt-get remove --purge blah-blah

> А менять /usr/bin на /usr/local/bin - все равно, что менять шило
> на мыло. Хорошие кандидаты на /opt: kde, gnome, xfce, mozilla

Щас! Уже разбежались...

А как быть с квантой (зависящей на KDE-libs)? А как насчет KOffice? А как быть с эволюшном (завязанным на gnome-libs)? А галеон, завязанный на мозиллу и гном одновременно? И таких примеров пруд пруди. Или ты предлагаешь выставлять библиотеки (они же не 'its static files') в /usr[/local]/lib, а сами приложения в /opt??? IMHO где-то вы ошибаетесь :-)

Лично меня пока что устраивает местоположение файлов (при условии наличия менеджера пакетов), а в /opt я бы селил только "самовлюбленных монстриков" типа Oracle/Informix/DB2/StarOffice etc.

2 Dselect

Йес, Ай'в юзд ит, бат ай префер зе гноум

/bin

> живущих в /bin. Убрать нахрен /usr/bin
ага, щаз. глупее ничего не придумал?
сразу видно, что никогда ничего рухнувшего не восстанавливал.;-)
это разделение было сделано НАМЕРЕНО, чтобы отделить КРИТИЧНЫЕ системыне проги от некритинчых.
критичные должны обеспечить запуск системы в single mode и восстановление системы. аналогично /lib, /usr/lib.

Ну, посмешил... Ну, революционер, блин :) Давно я так не веселился, честное слово. В общем, до основанья, а затем?
Давай ещё до кучи /sbin и /usr/sbin туда же сольём :) А чё их так много? И все вроде бинарии... Будет один бааааальшой /bin, да?
А всех монстров в резервацию в /opt/monster_name. У каждого свои lib, bin, share... Что-то виндой запахло, кажется... :)
Памятуя, что главный критерий истины - практика. А давай ты не декларации тут будешь разбрасывать, а собственный дистрибутив слепишь, где всё это и реализуешь. А мы потом оценим, что из этого вышло. Или слабО?

> NOT handling package dependencies [...] is EVIL

А не будет зависимостей в их тепершнем виде. Статическая сборка всех
побочных либ. Оставляем в динамике glibc и еще несколько самых
распространенных _базовых_ библиотек.

> Could you give any examples, please?

Странный вопрос. RH, Mandrake когда-нибудь видел?
Любой пакет со сложными зависимостями. Apache+php+perl+ssl+xml.
Замена (по необходимости) одного элемента может привести к сбою всей
"стройной" системы.

> No program is bugless.

Оправдание для бедных и слабых духом.

> It makes [security] updates, bug fixing, etc terribly painful.

Например?

> This staff seems to be defined by FHS.

А что, FHS перечисляет все программы? А где база данных? Как я могу
добавить в нее что-то?

> Could you explain please, WHY?

Потому что из /usr/bin сдеклали бесполезную свалку. Бесполезную
потому, что из полутора тысяч файлов реально используется единицы.

> That's wrong with /usr/sbin ?

Проблема та же, что и в случае с /usr/bin. Пример: там лежит sshd.
Кто и когда запускает эту прогу иначе, чем из скрипта запуска?
Если никто и никогда, то зачем она лежит в месте, которое прописано
в $PATH? Чем не свалка?

> А как быть с квантой (зависящей на KDE-libs)? А как насчет KOffice?

/opt/kde/bin/quanta
Кстати... не к ночи будет сказано... в slackware-9.1 она именно в этом месте и лежит... ;)

/opt/kde/bin/kword и т.п.

> А как быть с эволюшном

/opt/gnome-2.4/bin/evolution

> А галеон, завязанный на мозиллу и гном одновременно?

/opt/gnome/bin/galeon

> Лично меня пока что устраивает местоположение файлов

А меня перестало устраивать где-то на второй год общения с линуксом.

> сразу видно, что никогда ничего рухнувшего не восстанавливал.;-)

А ничего в нормально настроенной системе рушится и не должно... ;)
Кроме железа, конечно. Но ты же говоришь о программных сбоях,
я правильно понял? Никогда такого не было и не будет.

Идеи интересные, в чём-то правильные, но их пока ещё разрабатывать и разрабатывать дальше. Предложение насчёт /opt мне тоже чем-то импонирует, кстати. Но есть неясные места.

> Нужно завести единую для всех базу с уникальным
> проcтранством имен программ, живущих в /bin

Это как - базу? Как в винде ветвь реестра с путями exe-файлов установленных приложений, что ли? Ты только не забывай основное отличие винды от линукса. Винда старается сделать так, чтоб про командную строку все напрочь забыли и никто ей не пользовался. Потому удобства работы с консолью в винде минимальны. Линукс же мне, к примеру, нравится тем, что многое без проблем делается в терминале. Чем подобная база в принципе будет лучше, чем нынешние /bin и /usr/bin? В чём, собственно, выгода? В подмене файловой системы реестром? Или я чего-то не понял?
А где будут лежат бинарные файлы "монстров"? В /opt/monster_name/bin? Т.е. либо я не могу в консоли запустить этот файл из произвольного места, либо при установке этот пусть надо добавить в Вашу "базу", являющуюся в таком случае подменой PATH? А в чём выгода при переходе от чистой файловой системы к новой прослойке? Для файловой системы у меня есть mc. А для "базы" будем делать новый "редактор реестра"? Т.е. повторяем пусть M$? А надо ли? Или я опять чего-то не понял?

Далее.

> Нормальный новый package manager все равно придется писать, если есть
> желание ввести по-настоящемуц единый стандарт.

Вы, батенька, максималист. Вам бы ГОСТы издавать :) По комсомольскому задору сразу видно - ничего серьёзного Вы до сих пор не писали. Попробуйте, очень рекомендую. Действительность Вас скоро разочарует. Или Вы считаете себя первым настолько умным? Как Вы полагаете, сколько человек до Вас приходили к этой же великой мысли? Но светлое будущее что-то до сих пор не наступило, хотя package manager'ов много.
Для начала давайте перестанем сыпать направо и налево апрельскими тезисами, а очертим круг достоинств, которые будут выгодно отличать наш предполагаемый package manager от уже существующих. В чём будет его научная и практическая новизна? Начинайте, я приготовился слушать.

> Нужно так же определить
> минимальный круг общих динамических библиотек.

Вам бы на 30 лет назад раньше родиться - глядишь, и БАМ достроили бы сразу :)
Будете рассылать всем разработчикам письма с опросами, какие библиотеки им нужны? Или сами в приказном порядке решите? Это M$ хорошо так рассуждать, ибо она - хозяйка своей винды, а остальные пляшут под её дудку. А Вы попытаетесь насадить чуть ли не тоталитаризм в линуксе. Боюсь, не получится. Не пойдут массы за Вами. Ибо у каждого на этот счёт своё мнение.
Кроме того, Вы мыслите абсолютно не-диалектически. Вы хотите насадить один порядок раз и навсегда. Но всё развивается! Сейчас нужны одни библиотеки, завтра - другие... Нельзя, юноша, запихнуть столь подвижную систему, как линукс, в столь жёсткие рамки! Она, как вода, течь найдёт :)

> Остальное собирать
> статически. Нужно завести единую для всех базу с уникальным
> проcтранством имен программ, живущих в /bin. Убрать нахрен /usr/bin.
> Разную мегатонную хрень, типа KDE и Gnome бросать исключительно в
> /opt.

Так и хочется вытянуться по струнке. У нас новый кормчий, ей-богу :)

> Все сервисы бросать исключительно в /service.

Кто такой "сервис"? А XDM - сервис или нет?

> Короче, работы очень и
> очень много.

Хочется добавить: Все - на стройку светлого будущего! :)

> APT - это приятная игрушка для детей.

Но она, заметьте, работает и многих устраивает. В отличие от Ваших воздушных зАмков и грандиозных прожектов. Заканчивайте бросаться словами и докажите всё это на деле! :)

> А нужно еще РАБОТАТЬ ;)

Золотые слова, знаете ли :)

> Странный вопрос. RH, Mandrake когда-нибудь видел? Любой пакет со сложными зависимостями. Apache+php+perl+ssl+xml. Замена (по необходимости) одного элемента может привести к сбою всей "стройной" системы.

Видел (RedHat). Весьма удобно. Замены методом rpm -U -- делал. Иногда ругалось на зависимости, но тут уж _ничего_ не поделаешь -- если автор сказал, что для его проги нужен пакет ХХХ-1.2.4-8.11 и никакой другой, то что тебе сделает самый распрекрасный менеджер? Или ты про несовместимость новой версии пакета со старой? Опять же -- не проблема менеджера.

Вообще, при всей ругани на rpm каких-то неразрешимых проблем с ним (особенно при наличии srpmов) не наблюл и не чёл. Возможно, есть и поудобнее, не спорю...

Да, он используется только в RedHat (ну, ещё Мандрак, as я пол, есть возможность в Слаквари) -- но формат вполне гибок и подойдёт для любой системы, имхо. Уточняю: _формат_, не конретные пакеты. Хотя, имхо, srpm, с переконфигурацией должен бы встать на любой линух.

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

/bin

> ничего в нормально настроенной системе рушится и не должно
насчёт "не должно" - согласен. но есть теория и есть жизнь.
и случаи бывают разные. и именно по опыту я теперь бью / отдельно от /tmp & /usr & /var & /home - впрочем каждый сам себе Буратино.
я не буду прописные истины более объяснять - марш читать книжку керингана с пайком для начала.

> Это как - базу?

Глобальный реестр уникальных имен. Типа dns.

> Чем подобная база в принципе будет лучше, чем нынешние /bin и /usr/bin

База не для этого. Она - для поддержания уникальности имен программ, которые действительно необходимо держать в $PATH. Неважно, как будет
называться сама директория - /bin или /prog, но она должна быть одна.

> В чём, собственно, выгода?

В том же, в чем выгода единой базы dns. Сходство еще и втом, что и
приложения очень скоро будут запускаться не с локального диска, а из
инета. Уже есть такие разработки.

> А где будут лежат бинарные файлы "монстров"?

На усмотрение самих монстров. Где им удобнее. Можно оставить
классическую FHS-схему с одним изменением - вся иерархия каталогов
переносится ниже главного каталога программного пакета. Например,
/opt/kde/{bin,doc,lib,share}.

> Т.е. либо я не могу в консоли запустить этот файл из произвольного места

Mожешь, но в /bin нужно класть только саму запускалку, если она вообще
имеет смысл, а не все бинарники пакета-монстра.

> А для "базы" будем делать новый "редактор реестра"?

"База" реализуется средствами файловой системы. Невозможно в один
каталог добавить два неуникальных файла...

> на 30 лет назад раньше родиться - глядишь, и БАМ достроили бы сразу :)

Насколько я знаю, тот БАМ, который планировался при Брежневе давно
достроен.

> Будете рассылать всем разработчикам письма с опросами, какие библиотеки им нужны?

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

> Это M$ хорошо так рассуждать, ибо она - хозяйка своей винды, а остальные пляшут под её дудку.

В определенной степени то же самое можно сказать про любой линуксовый
дистр. Сколько всякой дряни потянулось от редхата в другие дистры?
Отличие от $M есть и очень важное. Всегда есть выбор! Всегда можно
изменить ход истории ;)

> Вы хотите насадить один порядок раз и навсегда.

Не навсегда, но на достаточно долгий срок. Обычно, если решение правильно продумано, оно живет очень долго.

> Кто такой "сервис"? А XDM - сервис или нет?

Сервис - это программный пакет, который запускается один раз и далее
работает автономно, обслуживая запросы по сети, либо через сокеты.
XDM я бы не стал выделять в отдельный сервис. Скорее он - составная
часть более крупного сервиса.

> и случаи бывают разные. и именно по опыту я теперь бью / отдельно от /tmp & /usr & /var & /home

Я тоже так делаю, но, тем не менее, никогда ничего не рушится.
А разбиение такое удобно по совсем другим причинам.

>Нет, это делается не так. Собирается статистика по используемым библиотекам. Не секрет, что есть такие библиотеки, которые используют одна-две программы. Далее производитель масштаба SuSe жестко описывает новый стандарт и выпускает дистр. Если он все продумал хорошо, и опыт удачный, то все остальные дистрописатели по неволе автоматом подтягиваются.

боже какой бред. никто никуда не подтянется. тоже мне масштаб нашел

Ооо... опять Dselect вылез. Ты уже бэкпортировал все, что тебе нужно в woody?

4DSelect
Не Point, а Period.

//Losiki

> В том же, в чем выгода единой базы dns. Сходство еще и втом, > что и приложения очень скоро будут запускаться не с локального > диска, а из инета. Уже есть такие разработки.

Эти "разработки" есть уже лет *дцать, и всё отлично работает уже сейчас. Если, конечно, не использовать кривые поделки, а нормальные программы.

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

То, что мы имеем сейчас, не идеально, то но, что ты предлагаешь ещё хуже. Сегодняшнее положение получилось эволюционным путём, это наиболее сбалансированный вариант.

И насчёт зависимостей. В нормальном дистрибутиве с зависимостями всё хорошо. А redhat - это redhat, а не нормальный дистрибутив. Про мандрейк вообще молчу.

>Короче могу поспорить - будет installer как на винде, и поставлятся

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

>дефолтным либам

>nuBo (*) (27.11.2003 13:53:20)

пробовал ASPLinux ставить?

>> Лично меня пока что устраивает местоположение файлов

>А меня перестало устраивать где-то на второй год общения с линуксом.

>anonymous (*) (28.11.2003 0:03:06)

Значит пора тебе свой дистр делать по своей схеме. Когда у него будет последователей хотя бы в половину от числа пользователей Mandrake, RedHat или SuSE, тогда можно говорить, что надо менять подход. Но такое гавно, какое ты описал ставить себе на комп не буду - мне наличие /bin, /usr/bin и т.д. устраивает, а директорию /opt стирать буду.

>То, что мы имеем сейчас, не идеально, то но, что ты предлагаешь ещё

>хуже. Сегодняшнее положение получилось эволюционным путём, это наиболее

>сбалансированный вариант.

>rk (*) (28.11.2003 10:38:02)

Вот именно. Люди читайте , что Вам умный человек по имени rk написал.

Эволюционный путь позоволяет добиться оптимальности по тем или иным критериям. Те дистрибутивы Linux, которые сейчас есть, устраивают тех или иных пользователей в зависимости от некоторых факторов. Если кого что не устравиает, он может свой дистрибутив сделать. Я на сервер и на десктоп разные дистрибутивы обычно ставлю. Enterprise ядро хорошо использовать на мощиных серверах, а на десктопах пойдет и обычное ядро. Истема XFree86 нужна на десктопе, а на сервере она не нужна, зато на сервере нажуны пакеты для безопасности сервера и сети.

О, мне уже и ответ написали, я гляжу. Надеюсь, по делу. Что ж, приступим. :)
Начнём с домашнего задания. Я имею в виду перечисление принципиальных отличий нашего нового менеджера пакетов от уже имеющихся. Простите, не вижу... Не справились? Ну что ж, ничего страшного. В конце концов, я сроки сдачи готового задания не оговаривал. Но к концу следующей недели хотелось бы иметь уже на руках. Можете на грядущих выходных обмазговать эту проблему.

> Насколько я знаю, тот БАМ, который планировался при Брежневе давно
> достроен.

Да. Но - не при Брежневе. Только в 1984 было открыто сквозное движение, и на этом работы ещё отнюдь не закончились. На досуге можете проглядеть , http://bam.railways.ru/history.html если имеются вопросы. А с Вашей энергией его, я полагаю, закончили бы, как пятилетку, - в три года :)

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

В данный момент! И только те, которые известны ЛИЧНО ВАМ! Вы уже очертили круг пользователей, на которых в основном будете ориентироваться? Это будут домашние пользователи? Ну что ж, тогда все математические специализированные библиотеки можно смело вычёркивать - они и правда дома никому не нужны.
Начинать надо с формулирования цели, постановки ЗАДАЧ, ограничения круга решаемых задач. Ваша цель - сделать линукс домашним десктопом? Или инструментом для решения прикладных задач, удобным учёным? Вы в курсе, чем универсальное решение отличается от узкоспециализированного? Вы постоянно норовите сползти в колею, уже проторенную M$.
Мы мне чем-то напоминаете молодого Александра I, который все свои 25 лет правления грозился дать России констритуцию, освободить крепостных и т.д., но с годами эти его позывы были всё тише и тише. Ибо умнел понемногу. Надеюсь, у Вас этот процесс тоже начнётся.

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

Вы, простите, не в Штатах сейчас живёте? Если не секрет? Просто узнаЮ образ мышления молодого наполеончика, весьма характерный для большинства тамошних менеджеров. Мало того - они ещё и верят в эти свои мыльные пузыри. А потом ещё возмущаются, почему остальные дистростроители плюнули на них и начали строить своё собственное светлое будущее.
Именно Вашим рецептам в своё время следовала фирма Caldera. И даже многое наворотить успела. Где все эти воздушные зАмки сейчас?
Линукс-сообщество слишком обширно и инерционно, чтоб его можно было заставить так быстро плясать под чью-то дудку. Тут надо всё делать постепенно и размеренно, обуздывая свои юношеские порывы.
Не сомневаюсь, что удачные решения они с Вас передерут. Но не все. И каждый - по своему. Ибо терять индивидуальность не хочет никто. Поймите же, что у каждого из них есть свои интересы, которые далеко не всегда совпадают с Вашими! Или будем душить всех несогласных? :)

> В определенной степени то же самое можно сказать про любой
> линуксовый дистр. Сколько всякой дряни потянулось от редхата в
> другие дистры?

Теперь Вы хотите, чтоб дрянь потянулась от Вас? :) Если Вы про mandrake, asp и пр., то они - типичные паразиты на теле RH. А теперь вспомним, что есть ещё Slackware, Debian и куча других. А есть ещё огромное количество мини-дистрибутивов, которым все эти ваши идеи на фиг не нужны, ибо перед ними описывамые Вами проблемы просто не стоят. Что с ними-то делать? Тоже навязывать Ваши новые стандарты? Или создавать круг "правильных" дистрибутивов, а остальные просто не замечать, как будто их нет?
Эти Ваши начинания, теоретически, могут прокатить, если их предложит сейчас SUSE, а RH радостно поддержит. ТОЛЬКО тогда можно ещё на что-то надеяться. Если же RH от Вас отвернётся, то максимум, на что может рассчитывать SUSE - это создать вильный и незалежный десктопный линукс, который многим будет нравиться, с которого начнут передирать удачные решения некоторые другие. Никакого стандарта не будет, будет море несовместимых реализаций одного и того же. Что только усугубит и без того печальную ситуацию.

> Отличие от $M есть и очень важное. Всегда есть выбор! Всегда можно
> изменить ход истории ;)

Не понял. КТО может изменить ход истории? Отдельно взятый мечтатель вроде Вас? Ну-ка, продемонстрируйте! :)

> Сервис - это программный пакет, который запускается один раз и далее
> работает автономно, обслуживая запросы по сети, либо через сокеты.
> XDM я бы не стал выделять в отдельный сервис. Скорее он - составная
> часть более крупного сервиса.

А именно - иксов? Т.е. Вы предлагаете загнать их в /service/X11, создать там для них свои /bin, /share, /etc ?

> Глобальный реестр уникальных имен. Типа dns.

В каком смысле уникальных? Чтобы другой разработчик не мог взять имя уже существующего продукта? Вы какую проблему этим решаете?

> База не для этого. Она - для поддержания уникальности имен программ,
> которые действительно необходимо держать в $PATH.

Кто будет решать, необходимо её держать в PATH или нет? Кто за меня будет решать, хочу я тот или иной бинарник запускать с командной строки или нет? Или я сам должен настраивать эту базу?

> Неважно, как будет называться сама директория - /bin или /prog, но
> она должна быть одна.

А остальные бинарники куда? Как в винде - пусть тихо лежат в своих каталогах в /opt/progname и не рыпаются?
Вам ещё одно домашнее задание - посмотреть, что лежит в /bin, а что - в /usr/bin. Сравнить и найти глобальные отличия. У Вас какой дистрибутив? У меня Slackware 9.1, и принцип разделения я вижу без труда.
Вообще, проблема загаживания /usr/bin имеет место быть. И решать её надо. Но Ваш метод меня не устраивает, ибо он неоправданно усложняет существующую схему, снижая её надёжность.

> В том же, в чем выгода единой базы dns. Сходство еще и втом, что и
> приложения очень скоро будут запускаться не с локального диска, а
> из инета. Уже есть такие разработки.

Ооооо... Маркетологов M$ наслушались, да? Как я люблю эти красивые переливающиеся мыльные пузыри :) И эту зависимость холодильника будущего от интернета. Сколько лапши навешано на уши и сколько ещё бабок за это состригут всевозможные остапобендеры :) Давайте, поскандируем: .NET, XML, ...!
Только вот M$ это всё надо, чтоб получить глобальную власть над всеми своими пользователями. А Вам-то зачем? Зачем носиться из крайности в крайность? То у нас всё запускается с локального диска, то у нас всё грузится с интернета. Человеку даны МОЗГИ, чтоб соображать, для чего новая техгология выгодна, а для чего - нет. А не чтобы все всё писали на .NET только потому, что это круто и что Билли что-то сказал.

> На усмотрение самих монстров. Где им удобнее.

Именно так сейчас и обстоит дело. И именно с этим Вы изначально собирались бороться - с загаживанием /usr/bin. Вернулись к тому, с чего начинали? Что-то Вы не слишком последовательны!

> Можно оставить
> классическую FHS-схему с одним изменением - вся иерархия каталогов
> переносится ниже главного каталога программного пакета. Например,
> /opt/kde/{bin,doc,lib,share}.

Уже почти как в винде. Осталось ввести реестр. Зачем тогда единый bin? Все бинарии - в /bin каталога своего приложения! Все независимы! Если кто-то решил написать что-то, используя компоненты этого приложения - пущай линкует статически. А то развели тут коммунизьм с беспорядочными половыми контактами! :)
А если я всё-таки хочу с кем-то линковаться динамически? Но Ваша железная воля уже решила за меня, что этому приложению линковаться с кем-то негоже (ибо его редко пользуют домохозяйки), поэтому все его файлы - в его подкаталоге, который ещё как-то найти надо... Что, будем ещё один реестр создавать, который хранит в себе пути приложений и где они хранят свои библиотеки?

> Mожешь, но в /bin нужно класть только саму запускалку, если она
> вообще имеет смысл, а не все бинарники пакета-монстра.

Эту идею я, кстати, считаю здравой. Каждое приложение представлено в /bin линком на её основной бинарий, лежащий в каталоге его приложения. Путём использования ключей меняется функциональность приложения, вызываются его разные функций. Теперь дело за малым - заставить всех поступать именно так :) Берётесь? :)

> "База" реализуется средствами файловой системы. Невозможно в один
> каталог добавить два неуникальных файла...

В смысле - неуникальных? Две разные версии одного и о же? С чем боремся-то?

Подытоживая. Ваши два основных тезиса:
1. Всем нужным (как Вам кажется) пользователям bin-файлам - единую свалку. Там и bash, там и lha. Приложения, как при коммунизме, стройными рядами идут в /service и /opt.
2. Создаём реестр уникальных имён бинариев, лежащих в этой свалке. Цель - сосчитать каждого из них и сделать его уникальным.
Так?
Что это всё нам даёт, кроме красивых слов, которые я уже прочитал? Можно, наконец, КОНКРЕТНЕЕ, без расплывчатых фраз в стиле M$, сформулировать по пунктам основные новвовведения?

Сразу прошу прощения за ляпы типа "обмАзговать" - нет времени перечитать всё, что набрал. Будьте снисходительны, это не от безграмотности, а автоматом :)

> Ооо... опять Dselect вылез. Ты уже бэкпортировал все, что тебе нужно в woody?

MPICH, GiNaC, g++, Mathematica, LaTeX work pretty good without any backports.