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

а на какие фичи так туманно намекается, на mount --bind чтоли?
Оно не "по видимому в версии 2.6" а с 2.4 как минимум.
На слаке, возможно, даже с 2.2.

Да, давненько я такого бреда не читал :-) Даешь новый /Program Files/Program/Version/Subversion и 1000 майнтпоинтов!!! :-)

А как быть с теми пакетами, которые и не должны располагаться в /usr/local, например mount, grep, pam, binutils и прочими? Или они типа за пакеты уже не считаются?

А если установлено 150 пакетов, их каталоги lib собраны на /usr/local/lib, в каждом пакете 10 билиотек... И теперь какая-нибудь программа пытается загрузить 15 библиотек. И что, ядро для каждой из них лезет в таблицу маунтов, видит что /usr/local/lib это union, пробегает по каждому элементу union'а в поисках нужного файла...

Нет, пусть лучше это бзд-ючники у себя реализовывают, а мы оставим mount для файловых систем :-)

P.S.: а почему мальчику не пришло в голову просто накидывать в /usr/local/xxx симлинки???

идиотический подход к управлению пакетами в UNIX

Опять этот C:\Program Files\ вылез...

В тему. В ASP 9.0 зависимости пакетов установлены так, что KDE нельзя поставить без Gnome.

> В ASP 9.0 зависимости пакетов установлены так, что KDE нельзя поставить без Gnome

Или все-таки без gnome-libs? :-)

Тебе 10 метров на гномовские библиотеки жалко? :-)

Ставь себе хоть замок на молнии на брюках на ширинке. Сейчас ты этим никого не испугаешь. Насмотрелись торчащий и не закрытый ничем. Почему дуракам из BSD пришлось малую песочницу организовывать? Дурилка и есть дурилка.

кстати а зачем КДЕ вдруг понадобились Gnome-libs даже?

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

Аналогия - в федорином Горе 2-м ставится python-gnome и т.д., которая судя по всему юзается только их конфигураторами, и для Gnome вобщем-то не нужна.

Статья эта - сопли. Ну, так, некие рассуждения в слух. Рекомендую
автору для начала провести исследование уже сделанных проектов по
данной тематике. Их десятки. Некоторым по многу лет и они активно
поддерживаются. Один из лучших примеров - epkg:
http://www.encap.org/epkg/
Изучите его внимательно. Там всё это уже реализовано и работает.

наглое вранье либо очень кривые руки

ну к примеру игры гномовские некторые тоже требуют питона

mount --bind совсем не то. Я не слышал чтобы в любимом линуксе была фича типа unionfs. Советуюю почитать что это такое и все станет ясно.

Пример из жизни - крутится 40 jail'ов на одном серваке. Так вот чтобы не клепать 40 файловых систем (тем самым сабивая и без того малюсенький сказочный хардец), делаешь один темплейт, и используешь его для всех джейлов. Места экономится %40-50.

> А как быть с теми пакетами, которые и не должны располагаться в /usr/local, например mount, grep, pam, binutils и прочими? Или они типа за пакеты уже не считаются?

Нет, не считаются. Если оно не в local, то оно - часть base system, и ставится через make world; во всяком случае, у людей =)

> А если установлено 150 пакетов, их каталоги lib собраны на /usr/local/lib, в каждом пакете 10 билиотек... И теперь какая-нибудь программа пытается загрузить 15 библиотек. И что, ядро для каждой из них лезет в таблицу маунтов, видит что /usr/local/lib это union, пробегает по каждому элементу union'а в поисках нужного файла...

А кто мешает оптимизировать ядро под такие вещи?

> а почему мальчику не пришло в голову просто накидывать в /usr/local/xxx симлинки???

Очевидно, потому что тогда удаление пакетов через rm работать не будет - останется туева хуча симлинков. Так что все равно придется заводить базу пакетов, чего он старается избежать.

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

> mount --bind совсем не то. Я не слышал чтобы в любимом линуксе была фича типа unionfs. Советуюю почитать что это такое и все станет ясно.

Почитал man mount_unionfs:

"THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. This code also needs an owner in order to be less dangerous - serious hackers can apply by sending mail to <hackers@FreeBSD.org> and announcing their intent to take it over."

И стало как-то не по себе =)

> Опять этот C:\Program Files\ вылез...

В таком случае FHS тоже пропагандирует C:\Program Files ;-) Вот она, грязная и немытая лапа Мелкософта - уже и до FHS добрались :-)))

> В таком случае FHS

"Лев был царь зверей. А по закону царей 3.14здить не положено. Но звери давно забили на закон."

s/Лев/FHS

Да кому он здесь нужен, этот FHS?

> Нет, ну надо было на английском запостить в ЛОР. Ведь сам же русский...

Это точно. Ведь давно известно, что пионерия на ЛОРе английского не знает.

> Нет, пусть лучше это бзд-ючники у себя реализовывают, > а мы оставим mount для файловых систем :-)

Ясное дело, BSD-шники дибилы. А так же дибилами являются RMS и его Hurd'овский зоопарк.

Но самые главные дибилы -- вот эти ребята:

Charles P. Wright PhD May 2003 Mohammad Nayyer Zubair MS May 2003 Jay Pradip Dave MS May 2003 - Dec 2003 Software Engineer, Zetta Systems Inc. (Woodinville, WA) Puja Gupta MS Jan 2003 - Dec 2003 File Systems Engineer, Apple (Cupertino, CA) Harikesavan Pathangi Krishnan MS Jan 2003 - Dec 2003 Tacit Networks (South Plainfield, NJ) Mohammad Nayyer Zubair BS May 2003 - Dec 2003 Stony Brook U. CS M.S. program (Stony Brook, NY)

http://www.fsl.cs.sunysb.edu/project-unionfs.html

UnionFS -- зло! Давить! Давайте дальше жить в помойке!

> P.S.: а почему мальчику не пришло в голову просто накидывать в /usr/local/xxx симлинки???

Потомо, что без них изящнее, тормоз. И 1000 mount-point'ов у тебя будет только если ты, как и подобает тормозу, зафигачишь в систему 1000 пакетов.

>>Нет, не считаются. Если оно не в local, то оно - часть base system, и ставится через make world; во всяком случае, у людей =)

Самый большой дебилизм, который есть в *BSD, это концепция base system, мешающая нормальному обновлению базового набора приложений и библиотек.

>А кто мешает оптимизировать ядро под такие вещи?

Тот факт, что ядро, затачиваемое под package manager -- плохое ядро. Не его ядреное это дело.

правильнее когда ядро отдельно, да ? :)

мальчик с феноманальной памятью...

> А кто мешает оптимизировать ядро под такие вещи?

Ох, не ядреное это дело...

> Очевидно, потому что тогда удаление пакетов через rm работать не будет

А оно и так не будет работать _корректно_.

> Так что все равно придется заводить базу пакетов, чего он старается избежать.

А запоминать, какой софтине чего нужно, и разруливать, в каком порядке их ставить/удалять этот мальчик с феноменальной памятью сам будет? ldconfig пущать, когда нужно и т.п.?

Все равно надо будет заводить базу пакетов, иначе получится та же помойка, что в windoze.

Я поначалу подумал (когда увидел слова про 2.6.x), что он базу собирается в xattr засунуть -- но нет, старый добрый идиотизмъ в запущенной форме...

> ldconfig пущать, когда нужно и т.п.?

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

что такое "вручную"

> А почему бы и нет? Подобную инфу вполне можно хранить прямо в директории пакета, вместе с зависимостями и прочей метадатой.

Таким образом, отличия от нормального package manager'-а сводятся к:

1) нарушению FHS

2) хранению кучи практически идентичных скриптов в директории каждого пакета, каждый из этих скриптов -- это недо-package manager, такой зоопарк выйдет...

Может, таки лучше, чтоб мухи были отдельно, а котлеты -- отдельно?

> Главное чтоб это не мешало ручной манипуляции.

А чем Вам dpkg в этом мешает?

> И 1000 mount-point'ов у тебя будет только если ты, как и подобает тормозу, зафигачишь в систему 1000 пакетов

А "чиста риальные патсаны" типа тебя предпочитают kde-libs, kdemultimedia, arts, kde-games, kde-libs-devel, kde-multimedia-devel, arts-devel и еще 50 компонентов держать одной большой кучей...

Давай-давай...

apt-get рулит не падецки

концепция base system позволяет разделить базу от остальной херни. и обновляется она с пол пинка.

Plan 9 -- вот кто рулит не по-детски.

Там объединения ФС реализованы изначально, а не натягиваются, как навороченный, но слишком маленький презерватив...

> концепция base system позволяет разделить базу от остальной херни.

Концепция base system vs все остальное живет от кривых рук и тяжкого наследия. named - это base или не base? Base. А dhcpd? Не base. А httpd? Снова не base. А почему один base, а другие нет? Ведь система и без named, и без httpd работоспособна?

А как определить влияние компонентов base на компоненты не base? На какие программы повлияет апдейт libnss_ldap.so?

какой такой kde-libs?

> А "чиста риальные патсаны" типа тебя предпочитают kde-libs, kdemultimedia, > arts, kde-games, kde-libs-devel, kde-multimedia-devel, arts-devel и еще 50

Не знаю, кто такие "чиста риальные патсаны", но у приличных людей перечисленное Вами барахло отсутствует как класс.

P.S.

Да, анонимус, конечно, бред несет.

P.P.S.

$ dpkg --get-selections | grep -e '\<install\>' | wc -l 868

> концепция base system, мешающая нормальному обновлению базового набора приложений и библиотек.

Я не понял, а чем тебя CVS и make world не устраивают?

> Тот факт, что ядро, затачиваемое под package manager -- плохое ядро. Не его ядреное это дело.

Я говорил не о затачивании ядра под pkg-manager (хотя, в пределах того, что пихается в ядро - почему бы и нет?), а о оптимизации unionfs.

> Ох, не ядреное это дело...

Хорошо, оговорюсь: ФС. Которая в данном случае входит в ядро, но вообще-то совершенно не обязана там быть. Так лучше?

> А оно и так не будет работать _корректно_.

Тпрру, а в чем дело? rm -rf /opt/pkg-name и все дела. Что не так?

> А запоминать, какой софтине чего нужно, и разруливать, в каком порядке их ставить/удалять этот мальчик с феноменальной памятью сам будет? ldconfig пущать, когда нужно и т.п.?

Депы естественно кидаются в папку самой софтины.

> Все равно надо будет заводить базу пакетов, иначе получится та же помойка, что в windoze.

Я так понял ему не нравится не идея базы сама по себе, а идея базы как физически отдельной сущности. Т.е. мысля была размазать ее по самим пакетам-каталогам на уровне ФС.

> 1) нарушению FHS

А был ли мальчик?

> 2) хранению кучи практически идентичных скриптов в директории каждого пакета, каждый из этих скриптов -- это недо-package manager, такой зоопарк выйдет..

О каких скриптах речь? Вроде говорили о депах и прочей metainfo? А манагер пакетов - отдельный скрипт, он сам по себе...

> А чем Вам dpkg в этом мешает?

Если ставить много софта ручками, и все в /usr (или куда там его dpkg ставит), то потом этот самый софт ручками тяжело выискивать и удалять.

> Не знаю, кто такие "чиста риальные патсаны", но у приличных людей перечисленное Вами барахло отсутствует как класс.

Покажите мне нормальный аудиоплеер под линух/бсд с библиотекой, масс-тэггингом, и распихиванием файлов по каталогам согласно тегам, кроме JuK (который входит в kde-multimedia).

> И стало как-то не по себе =)
Ну, у меня это приводило только к неожиданному кернелпанику и перезагрузке.
В общем, nfs рулит :D

> почему не пришло в голову просто накидывать в симлинки???

> Очевидно, потому что тогда удаление пакетов через rm работать не будет - останется туева хуча симлинков.

И что? Прошёлся ночером поиском, да и стёр. Вообще говоря, почему не кидать симлинки, я не понял ещё когда впервые сел на Линукс - RedHat 6.0

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

угу... давно уже пора древовидную фс изжить как класс - что-то типа ERFS нужно...

plan9 не plan9 - имеем простой интерфейс - файл называется, а сверху - бардак. Навесили бы на линюк что-то типа COM и пиздец - зависимости сразу видны, узнал GUID и скачивай нужный пакет

>> И 1000 mount-point'ов у тебя будет только если ты, как и подобает тормозу, зафигачишь в систему 1000 пакетов

>А "чиста риальные патсаны" типа тебя предпочитают kde-libs, kdemultimedia, arts, kde-games, kde-libs-devel, kde-multimedia-devel, arts-devel и еще 50 компонентов держать одной большой кучей...

У нормальных людей этого говна вообще нету.

> Если ставить много софта ручками, и все в /usr

НАХУЯ СТАВИТЬ СОФТ РУЧКАМИ??!!!! Это что, новый способ дрочить, или что? Сказал apt-get install, и поставил. Сказал apt-get remove, и удалил. Если надо пересобрать, то сказал apt-get source, и пересобрал.

Что только люди не придумают, лишь бы нормально не работать...

> > А "чиста риальные патсаны" типа тебя предпочитают kde-libs, kdemultimedia, arts, kde-games, kde-libs-devel, kde-multimedia-devel, arts-devel и еще 50 компонентов держать одной большой кучей...

> У нормальных людей этого говна вообще нету.

А вот теперь скажи, нормальный человек, как без artsd/esd или еще какого-нибудь аудиосервера запустить mplayer или xmms на компе "X", так, чтобы звук выводился на комп "Y"?

> аудиосервера запустить mplayer или xmms на компе "X", так, чтобы звук выводился на комп "Y"?

ясное дело. взять plan9 или qnx а не поделку студента... ;)

> Тпрру, а в чем дело? rm -rf /opt/pkg-name и все дела. Что не так?

Не, rm -Rf /opt/libblah-x.y.z просто так не сойдет.

Надо сначала узнать, не нужна ли какой-то софтине эта libblah, удалить таковой софт, после чего пущать ldconfig. Затем надо проверить, не остались ли какие-то пакеты, которые нужны только libblah, и с их тоже удалить.

> Депы естественно кидаются в папку самой софтины.

> Т.е. мысля была размазать ее по самим пакетам-каталогам на уровне ФС.

Ото я и говорю -- C:\Program Files\. Мож таки сначала надо понять, почему одни штуковины живут в /usr, а другие -- в /var?

модульность, твою дивизию...

> А вот теперь скажи, нормальный человек, как без artsd/esd или еще какого-нибудь аудиосервера запустить mplayer или xmms на компе "X", так, чтобы звук выводился на комп "Y"?

1) Пользовать нормальную ОСь, а не ....

2) А на# аудиосерверу вся эта Qета (kde-libs, etc)?!

> Если ставить много софта ручками,

1) А зачем?

2) А пакет собрать ну никак нельзя. Видать, за это дают 10 лет с конфискацией...

> А на# аудиосерверу вся эта Qета (kde-libs, etc)

Ок. А если я хочу собрать и запускать не XMMS, а kreversi (ну нравится мне как она играет)?

> Надо сначала узнать, не нужна ли какой-то софтине эта libblah, удалить таковой софт, после чего пущать ldconfig. Затем надо проверить, не остались ли какие-то пакеты, которые нужны только libblah, и с их тоже удалить.

Ты типа не понял =) Это - задача пакет манагера, отслеживание зависимостей etc, и он должен ее выполнять вне зависимости от организации файлопомойки на диске. Но если вдруг мне приспичило снести вот эту конкретную либу, и я отвечаю за то, что после этого все будет нормально - вот тут как раз rm замечательно сработает.

> Ото я и говорю -- C:\Program Files\. Мож таки сначала надо понять, почему одни штуковины живут в /usr, а другие -- в /var?

А он /var не трогает, он предлагает /usr раскидать.

> А пакет собрать ну никак нельзя. Видать, за это дают 10 лет с конфискацией...

Можно, но если сборка пакета состоит из ./configure --prefix=/opt/pkg-name && make && make install - жить проще.

>Я не понял, а чем тебя CVS и make world не устраивают?

Патамучта, бл...! За каким уем я должен держать 1) сырцы всего base 2) компилятор на _каждой_ своей машине (которых сейчас 2 десятка: Штаты, Словакия, 4 места в Киеве)? И компилять на каждой. Т.к. base system package'ами не поставишь. А о продолжительности downtime при апгрейде я вообще молчу... Необходимость сделать многое в single при обновлении системы меня убивает -- мне командировки не дают ради апгрейда. А сам процесс компиляния?! Машину загружены по самое нехочу (иначе это не серьезный проект), так я там еще N гигов под /usr/src, /usr/obj, /usr/ports (тоже не маленький) буду держать? И проц жрать компиляцией, когда у меня idle максимум 10%?

Нунах.

В общем-то согласен, но, только, непонятно - что это там такое интересное при апгрейде base необходимо делать в single?