В материале "GoboLinux and Replacing the FSH (http://osnews.com/story/20195/GoboLinux_and_Replacing_the_FS... представлены результаты обсуждения (http://forum.gobolinux.org/discussion/194/thoughts-on-goboli... проблем стандарта по организации иерархии файловой системы в Linux (FHS - Filesystem Hierarchy Standard (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)) и обзор альтернативного решения, представленного в дистрибутиве GoboLinux.
В GoboLinux используется (http://gobolinux.org/?page=at_a_glance) стековая модель формирования дерева файловой системы, при которой каждая программа устанавливается в отдельную директорию, для совместимости c FHS бинарные и конфигурационные файлы, а также библиотеки и логи распределены по стандарным /etc/, /bin, /lib, /var/log через символические ссылки. Минусом такого подхода является необходимость хранить данные (например, логи, файлы конфигурации) рядом с системными файлами, в обсуждении предлагается решить проблему через обрат...URL: http://osnews.com/story/20195/GoboLinux_and_Replacing_the_FSH
Новость: https://www.opennet.ru/opennews/art.shtml?num=17451
Я в линуксе не так давно (3-й год ) меня поначалу напрягало то что непонятно что где находится, а сейчас я даже вижу свои плюсы такого распределения файлов...
+1, в линуксе все логично распихано, более того даже в конце концов поизобретав велосипеды задолбался и честно спер иерархию в итоге.
X:\Program Files <-> /usr/bin
X:\Documents and Settings\user <-> /home/user
%WINDIR%\* и %WINDIR%\*SYSTEM* <-> /bin, /sbin и каталоги библиотек.
ну и в таком духе...Если в традиционной FHS иерархии сразу понятно - вон там программы, вон там shared данные программ, вон там логи а вон там конфигурация.
Использование 1 папки на программу... хм... каюсь, грешен, иногда и НЕКОТОРЫЕ сервисы я так люблю выносить в отдельные папки.Это нужно для того чтобы было проще держать интенсивно используемые и критичные сервисы под вниманием.Но если ВСЕ программы так будут распиханы, это чем-то напоминает подход... времен MS-DOS.Когда программы в силу отсутствия стандартных мест просто гадили в свои папки.
>неявность критериев распределения программ по директориям bin и sbinВсе очень даже явно - в sbin программы, которые имеет смысл запускать только от админа
ivan1986@ivan1986:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games
ivan1986@ivan1986:~$ su
Password:
ivan1986:/home/ivan1986# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin>рудиментарность таких директорий, как /opt, /usr/local и /usr/X11R6
согласен только с /usr/X11R6
/opt удобен для программ не из репозитария со своими инсталлерами
/usr/local очень правильная мысля для отделения прог, собранных из исходникови искать по папкам программ неудобно, неужели виндузятники прибежали и решили сделать такую же гадость как в винде?
>и искать по папкам программ неудобно, неужели виндузятники прибежали и решили сделать
>такую же гадость как в винде?Говорить "папка" - есть мышление виндузятника, не понимающего, почему этот термин логически никак не применим к понятию, которое он в это слово вкладывает.
Правильно говорить "каталог".
Ха.ХА. Есть к чему придратся. Да, это сильно посуществу.
правильно говорить "директория".
Слово "directory" переводится дословно как "справочник", что очень близко к "каталог". Слово же "директория" существует в языке лишь на правах слов "рутер", "файрвол", "свитч".
>Слово "directory" переводится дословно как "справочник", что очень близко к "каталог". Слово
>же "директория" существует в языке лишь на правах слов "рутер", "файрвол",
>"свитч".Поддерживаю. Такие слова допустимы в неформальном разговоре с коллегами, но вообще лучше употреблять слова "каталог", "маршрутизатор", "пакетный фильтр", "коммутатор" или "Ethernet-коммутатор".
Есть обоснование? По-моему лучше уж использовать транскрипции с буржуйского для таких терминов, тогда нет неопределенности в том, что имеется в виду.
>Есть обоснование? По-моему лучше уж использовать транскрипции с буржуйского для таких терминов, тогда нет неопределенности в том, что имеется в виду.Ну а где неопределённсть в названных русскоязычных терминах?
А у вас обоснование есть? Может вообще лучше на английском разговаривать? Я люблю свой язык и не использую НЕОПРАВДАННЫЕ англоязычные термины.
>А у вас обоснование есть? Может вообще лучше на английском разговаривать? Я
>люблю свой язык и не использую НЕОПРАВДАННЫЕ англоязычные термины.Вы о чём, коллега? Названные Вами слова -- "каталог", "маршрутизатор", "пакетный фильтр", "коммутатор" -- тоже отнюдь не русские. Точно такая же калька с иностранного (стыдливо именуемая "заимствованием"), только сделанная на пару-тройку веков раньше.
Что, возраст заимствования есть "ОПРАВДАНИЕ" его применению?
>>А у вас обоснование есть? Может вообще лучше на английском разговаривать? Я
>>люблю свой язык и не использую НЕОПРАВДАННЫЕ англоязычные термины.
>
>Вы о чём, коллега? Названные Вами слова -- "каталог", "маршрутизатор", "пакетный фильтр",
>"коммутатор" -- тоже отнюдь не русские. Точно такая же калька с
>иностранного (стыдливо именуемая "заимствованием"), только сделанная на пару-тройку веков раньше.
>
>Что, возраст заимствования есть "ОПРАВДАНИЕ" его применению?Да, возраст заимствование - оправдание. Если слово с похожим смыслом уже есть в языке, пусть тоже заимствованное, зачем заимствовать ещё одно? Неужели словам "рутер", "свич" и "хост" нет адекватных эквивалентов в русском языке? Есть, поэтому повторное заимствование считаю нецелесообразным.
>Ну а где неопределённсть в названных русскоязычных терминах?Неопределенность в том, что у одного термина несколько названий. Когда я только начинал осваивать профессию программиста и сисадмина, то я долго путался в роутерах/маршрутизаторах, коммутаторах/свичах.
>А у вас обоснование есть? Может вообще лучше на английском разговаривать? Я
>люблю свой язык и не использую НЕОПРАВДАННЫЕ англоязычные термины.Раньше, до того как выбрал и полюбил профессию программиста, более сильного врага "неоправданных заимствований" чем я сложно было найти. Но начав в большом количестве читать англоязычную литературу (не потому что русский разлюбил, а потому что нет русскоязычных аналогов) я несколько поменял свое мнение.
Я в предыдущем своем посте несколько невнятно выразился, но в целом я имел ввиду следующее:
Когда уже появился _устоявшийся в профессиональной среде_ русскоязычный термин (как маршрутизатор), то мне вообще пофигу кто какое слово упоминает. Но когда вводится _новый_ термин, то лучше использовать транскрипцию нежели придумывать дублирующую сущность.
>Неопределенность в том, что у одного термина несколько названий. Когда я только
>начинал осваивать профессию программиста и сисадмина, то я долго путался в
>роутерах/маршрутизаторах, коммутаторах/свичах.Думаю, что путались Вы именно из-за любителей неоправданно внедрять англицизмы.
>Раньше, до того как выбрал и полюбил профессию программиста, более сильного врага
>"неоправданных заимствований" чем я сложно было найти. Но начав в большом
>количестве читать англоязычную литературу (не потому что русский разлюбил, а потому
>что нет русскоязычных аналогов) я несколько поменял свое мнение.Ну этим Вы просто признались, что читая английскую литературу Вы начинали немножко думать по-английски. Это нормально, когда много читаешь на чужом языке. Но это не оправдывает замусоривание русского языка.
>Я в предыдущем своем посте несколько невнятно выразился, но в целом я
>имел ввиду следующее:
>Когда уже появился _устоявшийся в профессиональной среде_ русскоязычный термин (как маршрутизатор), то
>мне вообще пофигу кто какое слово упоминает. Но когда вводится _новый_
>термин, то лучше использовать транскрипцию нежели придумывать дублирующую сущность.Я бы сказал не просто _новый_ термин, а термин, которому трудно подобрать русскоязычный аналог. Делается это просто - нужно заглянуть в словарь, и если там найдётся подходящее по смыслу слово, то использовать нужно его. С другой стороны, не стоит искусственно придумывать называния для терминов, не имеющих адекватного перевода. Беда лишь в том, что граница эта часто нечёткая...
«Директория» — это из истории Украины начала XX века. Устоявшийся же в русскоязычной специализированной литературе перевод английского термина «directory» — «каталог».
>«Директория» — это из истории Украины начала XX века. Устоявшийся же в
>русскоязычной специализированной литературе перевод английского термина «directory» — «каталог».Помнится еще в 80-х годах в учебниках, словарях и книгах связанных с ЭВМ использовался именно термин "директория" и уже потом полезли каталоги и папки.
>согласен только с /usr/X11R6
>/opt удобен для программ не из репозитария со своими инсталлерами
>/usr/local очень правильная мысля для отделения прог, собранных из исходников/usr/X11R6 конечно рудимент, но множеству старых программ этот каталог требуется, поэтому символическую ссылку на него держать думаю стоит.
Вообще согласен, что главная проблема - это большая сложность организации совместного использования программ различных версий. Огромное количество зависимостей тоже проблема при обновлениях и т. д. Поэтому как сделано в PC-BSD иногда бывает удобно.
Но с другой стороны, администрировать и поддерживать в актуальном состоянии удобнее именно существующую иерархию. Вспоминаю M$ Windows, когда находят баг в библиотеке работающей с BMP рисунками, ты ставишь заплатку на системную библиотеку. И вроде всё хорошо и все счастливы, но ведь каждый пионер, наровит засунуть в дистрибутив своей программы копию этой библиотеки и использовать именно её. Поэтому в *BSD/Linux мне такого не надо, по крайней мере как стандарт.
>Все очень даже явно - в sbin программы, которые имеет смысл запускать
>только от админаC /bin и /usr/bin теже грабли. Проблема в том, что в разных дистрибутивах разные критерии отнесения программ к категории админских и минимально-необходимых. Где-то приходится писать /bin/ping, где-то /sbin/ping, где-то /usr/bin/ping, а где-то /usr/sbin/ping. Прописывать в скриптах полные пути - одно мучение.
>C /bin и /usr/bin теже грабли. Проблема в том, что в разных
>дистрибутивах разные критерии отнесения программ к категории админских и минимально-необходимых.Изначально в /bin лежали статически слинкованные утилиты, а в /usr/bin - динамически. При нормальной работе используются программы из /usr/bin.
А в аварийной ситуации, когда повреждены разделы /var или /usr, используются программы из /bin.
В bin лежат программы, не затрагивающие настройки системы. В sbin - изменяющие, в том числе доступные остальным пользователям, например passwd.
>такую же гадость как в винде?В винде от нее пытаются уйти в сторону того что нынче в линуксах.То есть, майкрософт всеми силами пытается заставить авторов программ гадить не в свою папку а в диру с юзерским профайлом.В висте гайки подтянули - писать в каталог program files стало тупо нельзя.Все записи редиректятся в виртуальный говноотстойник (крайне костыльный и горбатый аналог /usr/share получается).
IMHO, проблема несколько надуманная. Никогда не видел чтобы выполняли резервное копирование бинарей программ. Разве что при полном резервировании системы."Выделение всех файлов одной программы" не нужно - нужны только конфиги и данные - они лежат в четко указанных местах. Точно так же и /opt ни разу не устрела, вместе с /usr/local - ими часто пользуются для специфического софта.Если же рассматривается десктопное применение - автору лучше не изобретать велосипед с квадратными колесами и сферической рамой. Все равно пользователю за пределами $HOME реально ничего не видно.
>IMHO, проблема несколько надуманная. Никогда не видел чтобы выполняли резервное копирование бинарей
>программ. Разве что при полном резервировании системы."Выделение всех файлов одной программы"
>не нужно - нужны только конфиги и данные - они лежат
>в четко указанных местах.Все гораздо проще: Спросить у пакетного менеджера содержимое пакета.
>не нужно - нужны только конфиги и данные - они лежат
>в четко указанных местах.Вы правда не видели программ с конфигами в /var/lib/name/ и с данными в /usr/lib/name/ ?
Посмотрите, что rpm -q -a -c выдаст.
>>не нужно - нужны только конфиги и данные - они лежат
>>в четко указанных местах.
>
>Вы правда не видели программ с конфигами в /var/lib/name/ и с данными
>в /usr/lib/name/ ?
>Посмотрите, что rpm -q -a -c выдаст.Это проблема отдельных пакетов, отдельных мэйнтейнеров этих пакетов и отдельных пользователей, которым нужен такой пакет. В правильных системах с правильными пакетами и правильными мэйнтейнерами всё лежит в правильных местах.
>Это проблема отдельных пакетов, отдельных мэйнтейнеров этих пакетов и отдельных пользователей, которым
>нужен такой пакет. В правильных системах с правильными пакетами и правильными
>мэйнтейнерами всё лежит в правильных местах.Это не проблема мелких пакетов, а общая тенденция все сваливать в кучу. Яркий тому пример, я каждый раз плююсь выискивая в fedora и debian конфиг в котором описаны правила автомонитория. Знайте где он ? В /usr/share. А конфиги gconf в /var/lib как вам ?
> каждый раз плююсь выискивая в fedora и debian конфиг в котором описаны правила автомониторияАвто- чего?
>>Это проблема отдельных пакетов, отдельных мэйнтейнеров этих пакетов и отдельных пользователей, которым
>>нужен такой пакет. В правильных системах с правильными пакетами и правильными
>>мэйнтейнерами всё лежит в правильных местах.
>
>Это не проблема мелких пакетов, а общая тенденция все сваливать в кучу.
>Яркий тому пример, я каждый раз плююсь выискивая в fedora и
>debian конфиг в котором описаны правила автомонитория. Знайте где он
>? В /usr/share. А конфиги gconf в /var/lib как вам ?Значит что-то с головой у дистростроителей. Почему-то на фряхе я всегда могу сказать pkg_create -b и быть уверенным, что установленный софт снова завернется в пакет.
>debian конфиг в котором описаны правила автомонитория.А нельзя ли уточнить о чем вы?Название пакета в студию, вместе с путем к конфигу.
Вот честно - не врубаюсь что имелось в виду под "правила автомонитория".Авто?Монитория?Эээ... а монитория чего?
Ну я думаю этот чудный товарищ имеет ввиду таки автомонтирование. Только не ясно что конкретно он имеет ввиду. В общем по-моему бред и провокация :)
>Ну я думаю этот чудный товарищ имеет ввиду таки автомонтирование. Только не
>ясно что конкретно он имеет ввиду. В общем по-моему бред и
>провокация :)Нет, это правила втомонитория. И он каждый раз плюётся, выискивая их :)
Я после установки пакета могу посмотреть список файлов, которые он установил. Как правило, я очень быстро нахожу то, что мне нужно. В том числе легко находятся установленные страницы руководств, конфиги, исполняемые файлы.
>Вы правда не видели программ с конфигами в /var/lib/name/ и с данными
>в /usr/lib/name/ ?
>Посмотрите, что rpm -q -a -c выдаст.+1!
в последнее время все больше и больше пакетов, разработчики которых мягко говоря плохо представляют и не понимают куда что надо класть... примеров море! причем в их числе много известных широкоиспользуемых пакетов. Вот хотя бы MySQL... интересно каким боком /var/lib/ относится к базам данных?.. приметор море!
Вообще-то именно в /var/lib/mysql и место файлам данных MySQL. /var/lib/<program_name> специально для этого и существует. Другое дело, если база у вас серьезная и большая - никто не запрещает вынести ее в /d01 /d02 и т.п. А большинству юзеров это не надо, потому и /var/lib/mysql.
>>Вы правда не видели программ с конфигами в /var/lib/name/ и с данными
>>в /usr/lib/name/ ?
>>Посмотрите, что rpm -q -a -c выдаст.мне rpm -q -a -c | grep /usr/lib рассказал только про gconv (но данных я там не нашел), perl5 (я не перлист, но судя по всему там тоже только библиотеки), ну и jvm. Вот в /usr/lib/jvm действительно некоторый срач, но и то там данных не увидел.
Может назовете конкретный пакет и конкретный дистрибутив?
>+1!
>в последнее время все больше и больше пакетов, разработчики которых мягко говоря
>плохо представляют и не понимают куда что надо класть... примеров море!
>причем в их числе много известных широкоиспользуемых пакетов. Вот хотя бы
>MySQL... интересно каким боком /var/lib/ относится к базам данных?.. приметор море!
>-100 Читали стандарт то вообще? Вот цитата:
"/var/lib/ - Информация о состоянии. Постоянные данные, изменяемые программами в процессе работы (например, базы данных, метаданные пакетного менеджера и др.)"
Надо же! Придумали "гениальную" идею, а затем вручили ей костыли симлинков. Может проблема в том, что идея далеко не гениальная?
а головой подумать и самостоятельно поискать ответ слабо? они использовали линки как вынужденую меру, а не как фичу. RTFM.
>а головой подумать и самостоятельно поискать ответ слабо? они использовали линки как
>вынужденую меру, а не как фичу.Мне вот тоже кажется, что они использовали линки как вынужденную меру для подпорки своего ненужного изобретения, которое происходит из систем с безмозглым управлением ПО (и неумения студента-араба собрать пакет и договориться с сисадмином университетского тазика, чтоб его поставили/обновили).
В приличных системах и впрямь можно спросить пакетный менеджер о составе пакета. А ещё в приличных системах не хранят конфигурацию в /var/lib. Остальное же "избирательно бэкапить" смысла нет, поскольку проще apt-get reinstall пакет.
>RTFM.
RTFM что?
> А ещё в приличных системах не хранят конфигурацию в /var/libоднако, конфиги BIND`а - ALT Linux хранит в /var/lib/bind/etc/
>> А ещё в приличных системах не хранят конфигурацию в /var/lib
>
>однако, конфиги BIND`а - ALT Linux хранит в /var/lib/bind/etc/Наверняка они там хранятся по вполне объяснимой причине - bind запускается в chroot'е.
В var хранятся журнальные файлы, базы данных, DNS-зоны (чем не база данных?), веб-страницы. Всё это не является настройками, поэтому и лежит там.
>В var хранятся журнальные файлы, базы данных, DNS-зоны (чем не база данных?),
>веб-страницы. Всё это не является настройками, поэтому и лежит там.Да уж, генеальная идея положить БД рядом с логами, при классическом отдельном монтировании /var есть неплохой шанс, что при каком-нибудь флуде логи забьют раздел и развалят базу.
> Да уж, генеальная идея положить БД рядом с логами, при классическом отдельном
> монтировании /var есть неплохой шанс, что при каком-нибудь флуде логи забьют
> раздел и развалят базу.причина этих проблем не в том, что базы данных лежат на одном разделе вместе с логами,
причина проблем в том, что логи могут неконтролировано расти и занять все свободное место.
(то же самое будет и при наличии всей файловой системы внутри одного физического раздела)workaround: вынести /var/log на отдельный раздел. (причем, возможность такого workaround`а
в случае проблем - еще один громадный плюс традиционной файловой системы UNIX/Linux).
более желательный solution: устранить причину проблем (неконтролируемый рост лог-файлов).
>Да уж, генеальная идея положить БД рядом с логами, при классическом отдельном
>монтировании /var есть неплохой шанс, что при каком-нибудь флуде логи забьют
>раздел и развалят базу."Если вы такие умные, то почему строем не ходите?" -- в смысле монтируйте себе /var/lib и /var/log отдельными ФС и будет вам щастье.
Не надо валить на пакаджеров и "классическое монтирование" проблемы между локалстулом и локалкейбордом.
>>В var хранятся журнальные файлы, базы данных, DNS-зоны (чем не база данных?),
>>веб-страницы. Всё это не является настройками, поэтому и лежит там.
>
>Да уж, генеальная идея положить БД рядом с логами, при классическом отдельном
>монтировании /var есть неплохой шанс, что при каком-нибудь флуде логи забьют
>раздел и развалят базу.Серьезные базы данных там не хранятся. СУБД хранит свои файлы на RAW разделах (хотя алтернативная возможность есть - в продакшене таким пользоваться нельзя).
Поэтому при флуде `сломается` база данных нисколько не страшнее, чем то что при флуде некуда будет писать логи.
>> А ещё в приличных системах не хранят конфигурацию в /var/lib
>однако, конфиги BIND`а - ALT Linux хранит в /var/lib/bind/etc/Да, согласен -- равно как и других чрутизированных сервисов. На основные (вроде named.conf) может быть симлинк из традиционного места в /etc, но это скорее хинт для человека, чем машиноисполняемое указание.
Интересно, возможно ли случай с чрутами привести к приличному... :-)
>Да, согласен -- равно как и других чрутизированных сервисов. На основные
>(вроде named.conf) может быть симлинк из традиционного места в /etc, но
>это скорее хинт для человека, чем машиноисполняемое указание.
>
>Интересно, возможно ли случай с чрутами привести к приличному... :-)Мэйнтэйнеры ALT Linux подтянулись :)
>>> А ещё в приличных системах не хранят конфигурацию в /var/lib
>> однако, конфиги BIND`а - ALT Linux хранит в /var/lib/bind/etc/
> Да, согласен -- равно как и других чрутизированных сервисов. На основные
> (вроде named.conf) может быть симлинк из традиционного места в /etc, но
> это скорее хинт для человека, чем машиноисполняемое указание.в других системах bind может быть как chrooted так и не chrooted,
в этом случае /etc/named.conf - это не симлинк, а настоящий файл.
> Интересно, возможно ли случай с чрутами привести к приличному... :-)через mount --bind или более специфичные патчи к ядру ? наверное оно того не стоит.
кроме того, как быть с тем, что "chroot is not and never has been a security tool" ?"случай с чрутами привести к приличному" можно будет только одним способом -
сделав каждой программе свой собственный каталог, например, как портах FreeBSD.
>в других системах bind может быть как chrooted так и не chrooted,
>в этом случае /etc/named.conf - это не симлинк, а настоящий файл.Это понятно, просто мне лично системы, где bind до сих пор по умолчанию не в чруте, априори неинтересны/неправильны.
>кроме того, как быть с тем, что "chroot is not and never
>has been a security tool" ?Наш security officer замечен в симпатии к пустым readonly чрутам, а также чрутам без бинарников с suid/sgid, в которых код выполняется с уже пониженными после запуска привилегиями; смею заверить, что в таких случаях chroot -- это достаточно серьёзное дополнительное препятствие. Хоть и не панацея, как и контейнеры.
Но это не о том...
Немного вернусь назад.То, что программы, помещённые в chroot не вписываются в иерархию пактов доказывает лишь то, что chroot либо изначально не предназначен для защиты демонов, либо просто неправильно сделан.
Для защиты сервисов было бы разумнее сделать специальное средство, работающее на уровне ядра, которое изолировало бы определённый процесс доступом только к определённым файлам. Нечто вроде acl для каждого из сервисов, сюда же можно было бы добавить отдельные настройки фаерволла. Но всё это уже медленно переходит в идею паравиртуализации.
Мне кажется, что в настоящее вреям именно паравиртуализация - самое лучшее средство защиты сервисов.
>Мне кажется, что в настоящее вреям именно паравиртуализация - самое лучшее средство
>защиты сервисов.На практике мне тоже так кажется, но и из чрутов не вытаскиваю...
> То, что программы, помещённые в chroot не вписываются в иерархию пактов доказывает
> лишь то, что chroot либо изначально не предназначен для защиты демонов,
> либо просто неправильно сделан.изначально не предназначен. http://lwn.net/Articles/252794/
> Для защиты сервисов было бы разумнее сделать специальное средство, работающее на уровне
> ядра, которое изолировало бы определённый процесс доступом только к определённым файлам.
> Нечто вроде acl для каждого из сервисов, сюда же можно было бы добавить
> отдельные настройки фаерволла.и такое средство уже существует, и называется оно SELinux
например, apache хоть и не chroot но он достаточно жестко ограничен средствами policy.
как по доступным ему файлам/каталогам, так и по портам.> Но всё это уже медленно переходит в идею паравиртуализации.
> Мне кажется, что в настоящее вреям именно паравиртуализация -
> самое лучшее средство защиты сервисов.паравиртуализация - это XEN и UML.
OpenVZ - это не паравиртуализация.делать каждому демону свой собственный контейнер - это приведет
к увеличению сложности системы и усложнит администрирование,
особенно, если какие-то демоны должны будут взаимодействовать между собой.
и там останется только единственное средство для IPC - стек tcp/ip протоколов?да и вместо 10-100 машин администрировать 1000 - 10_000 различных контейнеров...
делать каждому демону свою собственную виртуальную машину XEN - это еще хуже.
поэтому на первый и на второй взгляд SELinux кажется более оптимальным решением.
>делать каждому демону свой собственный контейнер - это приведет
>к увеличению сложности системы и усложнит администрированиеПо крайней мере с некоторыми типами контейнеров возможно в рамках одного корня организовать разные контексты -- Петя Савельев в RADLinux когда-то так делал на vserver (эмбедщина по сути). Насколько качественно изолирует -- не скажу, не всматривался.
>особенно, если какие-то демоны должны будут взаимодействовать между собой.
>и там останется только единственное средство для IPC - стек tcp/ip протоколов?Нуу ещё бывает shm и вообще-то сокеты можно mount --bind, но это всё работа пинцетом.
>поэтому на первый и на второй взгляд SELinux кажется более оптимальным решением.
Когда работает. :) Задачи бывают разные, для многих куда проще сделать полупустой контейнер без лишних привилегированных бинарей, чем пытаться добить политику.
>Интересно, возможно ли случай с чрутами привести к приличному... :-)По моему это одно из немногих мест где вариант с "1 каталог на программу" имеет право на жизнь.Вот что-что а в чрут потом такое запихивать намного удобнее.
>>Интересно, возможно ли случай с чрутами привести к приличному... :-)
>По моему это одно из немногих мест где вариант с "1 каталог
>на программу" имеет право на жизнь.Вот что-что а в чрут потом
>такое запихивать намного удобнее.Так чрут в любом разе (в штатном альте, по крайней мере) один на программу. Причём есть тулза для автоматического поддержания -- update_chrooted(8) из пакета chrooted. Довольно занятная, хоть и простая.
To есть 'named' будет там же? под chroot? тогда прощай безопастность ;)))Изначально /var/lib/<name> задумывалось как отдельного места для пакета на /var, пусть оно так и будет.
В принципе, для данных есть /srv/<name> , тут и надо разворачивать базы данных.
>To есть 'named' будет там же? под chroot? тогда прощай безопастность ;)))
>
>Изначально /var/lib/<name> задумывалось как отдельного места для пакета на /var, пусть оно так и будет.верно. но только вот chroot BIND`а не очень подходит под это определение.
хотя бы потому, что ему для работы нужны файловые системы /dev и /proc
наверное поэтому в RHEL named вынесли в отдельный каталог /var/named> В принципе, для данных есть /srv/<name> , тут и надо разворачивать базы данных.
данные. но не chroot`ы же. tradeoff между безопасностью и удобством пользования.
была выбрана безопасность. согласно настроек SELinux - BIND может писать только
в каталоги /var/named/chroot/var/named/data и /var/named/chroot/var/named/slaves
и может только читать содержимое каталога /var/named/chroot/var/named, в котором
лежат мастер-зоны. так что даже если и сломают BIND, master-файлы он не испортит
>наверное поэтому в RHEL named вынесли в отдельный каталог /var/namedОй, а давно /вынесли/-то? Я вот думаю, что это просто ещё одна окаменелость в RHEL.
>> в RHEL named вынесли в отдельный каталог /var/named
>
> Ой, а давно /вынесли/-то? Я вот думаю, что это просто ещё одна окаменелость в RHEL.1) "А ещё в приличных системах не хранят конфигурацию в /var/lib" (с) Michael Shigorin
кто виноват в том, ALT Linux не соответствует твоим представлениям
о том, что такое "приличная" и "неприличная" операционная система.2) ты лучше FHS почитай, прежде чем фантазировать на предмет "окаменелостей" в RHEL.
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLES...
/var/lib : Variable state information
Purpose
This hierarchy holds state information pertaining to an application or the system.
State information is data that programs modify while they run, and that pertains
to one specific host. Users must never need to modify files in /var/lib
to configure a package's operation.
>>> в RHEL named вынесли в отдельный каталог /var/named
>> Ой, а давно /вынесли/-то? Я вот думаю, что это просто ещё одна окаменелость в RHEL.
>1) "А ещё в приличных системах не хранят конфигурацию в /var/lib" (с)
>Michael ShigorinНу да. Но /var/named -- это вообще порнография.
>кто виноват в том, ALT Linux не соответствует твоим представлениям
>о том, что такое "приличная" и "неприличная" операционная система.Моим _озвученным_ представлениям ;) Насчёт чрутов при озвучивании не подумал (работают себе где-то, не трогай). Реальных неприличностей хватает, но в других местах.
>2) ты лучше FHS почитай, прежде чем фантазировать на предмет "окаменелостей" в
>RHEL.Ты лучше покажи в FHS пункт про /var/named.
>Users must never need to modify files in /var/lib
>to configure a package's operation.А этим пойду ldv@ пужать, как из отпуска вернётся. :)
>>>> в RHEL named вынесли в отдельный каталог /var/named
>>> Ой, а давно /вынесли/-то? Я вот думаю, что это просто ещё одна окаменелость в RHEL.
>> "А ещё в приличных системах не хранят конфигурацию в /var/lib"
>
> Ну да. Но /var/named -- это вообще порнография.
>
> Насчёт чрутов при озвучивании не подумал (работают себе где-то, не трогай)."вообще порнография" - это вариант /var/lib/named по причине прямого нарушения FHS.
"критикуя - предлагай". какой вариант расположения по твоему мнению будет лучше,
/named
/srv/named
/chrooted-services/named ?> Ты лучше покажи в FHS пункт про /var/named.
в самом начале документа:
"This standard consists of a set of requirements and guidelines for file and directory
placement under UNIX-like operating systems. The guidelines are intended to support
interoperability of applications, system administration tools, development tools,
and scripts as well as greater uniformity of documentation for these systems."requirements не нарушаются, guidelines соблюдаются.
по крайней мере, никакого другого места в файловой системе для chroot`а BIND`а
более удачного нет. потому что там внутри chroot`а будет монтироваться /dev и /proc
их наличие внутри /var/lib - совершенно unexpected.>> Users must never need to modify files in /var/lib
>> to configure a package's operation.
>
> А этим пойду ldv@ пужать, как из отпуска вернётся. :)есть шансы, что ALT Linux станет приличной системой ?
мб хранить конфиги в /etc а chroot-каталог создавать перед запуском демона? просто копировать конфиг из /etc в /var/lib/bind/etc. Я так понимаю он его не перечитывает в процессе работы?
Я за распределение программ по своим каталогам :)
Только не надо делать симлинки на всё и вся.
Возможен более гибкий подход, тока он ещё не придуман :) "Всё гениальное просто"
>Я за распределение программ по своим каталогам :)
>Только не надо делать симлинки на всё и вся.
>Возможен более гибкий подход, тока он ещё не придуман :) "Всё гениальное
>просто"Если у тебя система на rpm/dpkg, то заходишь в mc в #rpms или #dpkg, и видиш каждую програму в отдельном каталоге. В чём проблема то?
что-то мне это напоминает....
а как теперь бинари запускать из комстроки?
PATH раздуется до невероятных размеров?
так они ж пишут у них там милиарды симлинков на все случаи жизни.
вобщем очередной костыль имхо
насколько я понимаю, бэкап пакета - это сохранение пакета и его конфигов
чем плох полный бэкап /etc
ценность в основном имеют конфиги. для бекапов пакетов есть специальные иинструменты. в Gentoo например есть quickpkg gcc. Собранный и установленный gcc соберется в tar.bz2 + гентушные примочки, но проигнорирует конфиги :)
мухи отдельно. котлеты отдельно.
Мндяяяяяя...
Как то услышал - "Любое сокращение штата на предприятии замысливается для его увеличения"
Тут файл+ссылка преподносится как наведение прядка? Чёт сомневаюсь...
s/директория/каталог/g
Каждое приложение должно иметь свою виртуальную структуру каталогов, в которой оно хочет иметь присутствие.
Для примера:
/Program1
|-bin
|-lib
|-doc
|-etcВсё это отображается на реальную файловую систему, например в такую:
/usr/local
|-bin
|-lib
|-doc
|-etcПри этом облегчается задача деинсталлятора — он просто удаляет виртуальную структуру каталогов приложения и всё!
Что касается разделяемых библиотек, то необходимо придумать механизм "обобществления" виртуальных подкаталогов /lib установленных приложений, подсчёт ссылок на нужные библиотеки, в том числе на зацикленных графах и т.д. При удалении приложений с разделяемыми библиотеками вопросы нужности/ненужности библиотек должны решаться.
Версионность библиотек должна быть совмещена с их именем в метаданных виртуальной системы каталогов, так как виртуальные каталоги подходят для хранения различных версий библиотек, файлы которых имеют одно и то же имя.
Дык, что-то такое они и хотят сделать. Вот только думается мне, что решать эту задачу нужно не на уровне ОС и ссылок, а на уровне ФС.
Подобное предлагал и передлагаю сделать:
http://gentoo.ru/node/4212
Идея интересная, даже лучше, чем в Гобо. Ибо в Гобо попахивает Виндузятиной с их Программы систем и т.д., пусть Кесарю кесарево, а Богу Божье. Но по мне - так лучше четкая стандартизация, хотя на десктопах было бы нужнее, т.к. пользователю нужно постоянно инсталлировать, деинсталлировать и т.д.
про данный изврат я уже писал на gentoo.ru оно не надо
обычная юниксовая иерархия проще и понятнее не надо городить огород с сылками черезпопными ид каталогов и тд. Если тебе это нраавится то юзай но не надо другим навязывать
Это ты своё мнение другим не навязывай.
Ссылки в предложенной идее - рудимент для совместимости, от которого в перспективе стоит вообще избавиться.
>рудимент для совместимости, от которого в перспективе стоит вообще избавиться.Ну-ну. MS вот от 16-битной совместимости не может избавиться.
Безумству молодых, сильных и впечатлительных поём мы кругом марш...
Нужно понимать что сказанное соотносительно предложеному, а на вообще в целом.А опус о молодых приберегите для юнцов...
>Подобное предлагал и передлагаю сделать:
>http://gentoo.ru/node/4212Почитал и поддерживаю void. Хватает нормальных менеджеров пакетов, если нужно несколько версий одной программы (тестеру видимо), то хватит prefix, ну там chroot накрайняк.
на самом деле проблема есть. в линухе с организацией файлов бардак.(хотя думаю от дистриба зависит).
во фре, например, софт ставиться в /usr/local/
а там, /usr/local/etc, /usr/local/bin и т.д.
что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local
все просто и логично.
>на самом деле проблема есть. в линухе с организацией файлов бардак.(хотя думаю
>от дистриба зависит).
>во фре, например, софт ставиться в /usr/local/Вы бы всё-таки перестали попугаить эту ерунду. "В линуксе" с организацией файлов бардака как раз на порядок меньше, чем во фре: в /usr/local собранное _локальным_ администратором, в /usr -- установленное системно при помощи средств управления ПО.
Как во фре предлагаете различать собранное из портов и руками из тарбола, который в портах отсутствует? В /opt ставить? ;-)
> что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local
> все просто и логично....для очень нужной задачи "получить никому не нужную голую систему".
>>на самом деле проблема есть. в линухе с организацией файлов бардак.Бардака нет. В системе, где всё - пакет, и даже ядро можно обновить пакетом, не имеет смысла искусственно делить каталоги на системные и каталоги для прикладных программ.
>> что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local
>> все просто и логично.
>...для очень нужной задачи "получить никому не нужную голую систему".Голая FreeBSD может роутить пакеты и быть фаерволлом, только преимущество "получить девственно чистую систему" мне кажется весьма сомнительным.
>в /usr/local собранное _локальным_ администратором,
>в /usr -- установленное системно при помощи средств управления ПО.Во FreeBSD: в /usr - базовая система, /usr/local - софт собственно FreeBSD _не_ являющийся ... но это же сложно и нелогично!, это же надо иметь степень доцента философии как минимум чтобы просто понять! Бедный Миша ...
>Как во фре предлагаете различать собранное из портов и руками из тарбола,
>который в портах отсутствует? В /opt ставить? ;-)Во FreeBSD предлагается сделать порт (это просто) и устанавливать уже его. Как впрочем и во всех вменяемых линуксах - только там слово "порт" заменяют на слово rpm, deb, ebuild, whatever ... В AltLinux всё не так? Тем хуже для Альта!
Впрочем предвижу - ты затянешь волынку на тему а как без этого ... ну ответ всегда один - раз делаешь руками - вся ответственность на тебе! Хочешь - ложи в /opt (но его по дефолту вообще нет ,) - хочешь ложи на общую для LAN NFS-шару - всё в руках _твоих_. Но если чего угробишь и вини - себя. Назови мне систему где это не так?!>> что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local
>> все просто и логично.
>...для очень нужной задачи "получить никому не нужную голую систему".Да - задача сомнительная :) Но задача "отказаться от FSH чтобы можно было иметь 2 версии одного софта" - вообще что то феерическое :)
GR.
>Во FreeBSD: в /usr - базовая система, /usr/local - софт собственно FreeBSD
>_не_ являющийся ... но это же сложно и нелогично!, это же
>надо иметь степень доцента философии как минимум чтобы просто понять! Бедный
>Миша ...Вообще-то я слегка в курсе, что куда суют по ФС во фре. Даже со своей скромной магистерской степенью. Не стоит так переживать :)
>>Как во фре предлагаете различать собранное из портов и руками из тарбола,
>>который в портах отсутствует? В /opt ставить? ;-)
>Во FreeBSD предлагается сделать порт (это просто) и устанавливать уже его.
>Как впрочем и во всех вменяемых линуксах - только там слово "порт"
>заменяют на слово rpm, deb, ebuild, whatever ...Я опять же в курсе, как рекомендуется. И поддерживаю порядка двухсот пакетов. При этом не верю, что уважаемый аноним всё всегда ставит из портов/пакетов -- равно как и десять тыщ мильёнов его коллег по цеху.
>Впрочем предвижу - ты
Мы с Вами разве пили на брудершафт?
>затянешь волынку на тему а как без этого
Не-а, потому что прекрасно знаю, как. Вот только практика показывает, что знают-то не все, не то что следуют таким рекомендациям.
Собсно новость тому ярким подтверждением.
>... ну ответ всегда один - раз делаешь руками - вся
>ответственность на тебе!Именно ;-)
>>...для очень нужной задачи "получить никому не нужную голую систему".
>Да - задача сомнительная :) Но задача "отказаться от FSH чтобы можно
>было иметь 2 версии одного софта" - вообще что то феерическое
>:)О чём, собственно, и речь :-) (btw "FHS")
>>:)
>О чём, собственно, и речь :-) (btw "FHS")Очепятки happen :)
Миша - не обижайсо, на "ты" я не со злобы! Но будь реалистом - это общепринято.Главное же в нашем разговоре не это. Вот смотрите: он - Линуксоид, я - больше Фряшник. А по всем главным моментам у нас подозрительно схожие мнения. Думаю это потому что есть инженерный подход (да-да - седая классика, анализ\синтез) и он приводит к FHS и пакетным менеджерам. А есть буйная анархия\фантазия\право делать глупости ... которая тоже нужна - ибо без этого новых идей и не будет. Только новые идеи все равно попадают на зубок к инженерам ... которые их либо принимают и воплощают в реальность ... либо подумав над "этим Goblinux-ом" откладывают.
В данном конкретном случае решение приносит больше проблем, чем пользы ==> "в сад!"
Вот такое HO.GR.
>Миша - не обижайсо, на "ты" я не со злобы! Но будь
>реалистом - это общепринято.Помнится, у фидошников -- но не в моём обычном кругу общения.
>Главное же в нашем разговоре не это.
Так отож ;-)
>>на самом деле проблема есть. в линухе с организацией файлов бардак.(хотя думаю
>>от дистриба зависит).
>>во фре, например, софт ставиться в /usr/local/
>Вы бы всё-таки перестали попугаить эту ерунду. "В линуксе" с организацией
>файлов бардака как раз на порядок меньше, чем во фре:ну-ну..
>в /usr/local собранное _локальным_ администратором, в /usr -- установленное системно при помощи
>средств управления ПО.Ничего не понял. pkg_add, make install, portupgrade считаются системными средствами управления ПО?
>Как во фре предлагаете различать собранное из портов и руками из тарбола,
>который в портах отсутствует? В /opt ставить? ;-)Нормально прописывать префикс при configure. 70% патчей в портах этим и занимается.
Можно и в порт завернуть.>> что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local
>> все просто и логично.
>...для очень нужной задачи "получить никому не нужную голую систему".где в начальном посте говорилось о "очень нужной задаче"?
>>в /usr/local собранное _локальным_ администратором, в /usr -- установленное системно
>>при помощи средств управления ПО.
>Ничего не понял.Человеку на пальцах объяснил семантику /usr{,/local} _в линуксе_. Наверное, стоило ещё добавить, что нет разделения на "базовую систему" и "софт второго класса" -- всё, установленное из пакетов дистрибутива, относится к дистрибутиву. Подход другой.
>pkg_add, make install, portupgrade считаются системными средствами управления ПО?
Первое и последнее -- да, второе -- смотря где делать. Подразумевалось же в /usr/ports? :)
>>Как во фре предлагаете различать собранное из портов и руками из тарбола,
>>который в портах отсутствует? В /opt ставить? ;-)
>Нормально прописывать префикс при configure. 70% патчей в портах этим и занимается.
>Можно и в порт завернуть.Эт понятно, но предложение подумать было не к Вам :) (хотя...)
>>>в /usr/local собранное _локальным_ администратором, в /usr -- установленное системно
>>>при помощи средств управления ПО.
>>Ничего не понял.
>Человеку на пальцах объяснил семантику /usr{,/local} _в линуксе_. Наверное, стоило ещё
>добавить, что нет разделения на "базовую систему" и "софт второго класса"
>-- всё, установленное из пакетов дистрибутива, относится к дистрибутиву. Подход
>другой.
>>pkg_add, make install, portupgrade считаются системными средствами управления ПО?
>Первое и последнее -- да, второе -- смотря где делать. Подразумевалось
>же в /usr/ports? :)уже потом увидел, что тут речь про линуксовый FHS.
>Вы бы всё-таки перестали попугаить эту ерунду. "В линуксе" с организацией
>файлов бардака как раз на порядок меньше, чем во фре: в
>/usr/local собранное _локальным_ администратором, в /usr -- установленное системно при помощи
>средств управления ПО.В каталог /usr ставятся приложения во время пересборки мира.
При помощи средств управления ПО (утилиты pkg_*) формируются подкаталоги каталога /usr/local.>Как во фре предлагаете различать собранное из портов и руками из тарбола,
>который в портах отсутствует? В /opt ставить? ;-)Написать свой порт. Это относительно несложно, зато он будет подчиняться правилам установки/удаления программ во FreeBSD и не замусорит систему.
> Как во фре предлагаете различать собранное из портов и руками из тарбола,
> который в портах отсутствует?Собрать надо порт, и все дела.
Гемора гораздо меньше, чем руками, и удовольствия больше, особенно если левой.
>> Как во фре предлагаете различать собранное из портов и руками из тарбола,
>> который в портах отсутствует?
>Собрать надо порт, и все дела.Повторюсь: я в курсе, как "надо". Все ли в курсе (и следуют ему) из использующих?
>>> Как во фре предлагаете различать собранное из портов и руками из тарбола,
>>> который в портах отсутствует?
>>Собрать надо порт, и все дела.
>
>Повторюсь: я в курсе, как "надо". Все ли в курсе (и
>следуют ему) из использующих?Все ли собирают честный пакет на RPM когда нет готового?
>Все ли собирают честный пакет на RPM когда нет готового?Если это несколько скриптов с парой конфигов или веб-интерфейс, то пакет не собираю.
Если это программа с make-файлом, то пытаюсь использовать хотя бы checkinstall для сборки deb-пакетов.
>>Все ли собирают честный пакет на RPM когда нет готового?
>
>Если это несколько скриптов с парой конфигов или веб-интерфейс, то пакет не
>собираю.
>Если это программа с make-файлом, то пытаюсь использовать хотя бы checkinstall для
>сборки deb-пакетов.dh-make?
>dh-make?Каюсь, грешен, до сих пор ещё не удосужился изучить инструменты разработчика debian. Хотя уже скачал и распечатал руководство на русском.
>>>> Как во фре предлагаете различать собранное из портов и руками из тарбола,
>>>> который в портах отсутствует?
>>>Собрать надо порт, и все дела.
>>Повторюсь: я в курсе, как "надо". Все ли в курсе (и
>>следуют ему) из использующих?
>Все ли собирают честный пакет на RPM когда нет готового?Воот. Не все. Но для лодырей и есть /usr/local. Я ж к чему подводил? ;-)
PS: сам несколько лет тому устрожил на localhost принцип "почти никогда не ставить самосбор в /usr/local" до "или оно запускается из ~/src, или собирается в пакет и устанавливается" после довольно неочевидной отладки чего-то падавшего, пока не догадался ldd на бинарник дёрнуть...
*девственную
а как же база данных установленных пакетов? ее же тоже надо удалить для "девственнизации" системы :-)
>а как же база данных установленных пакетов? ее же тоже надо удалить
>для "девственнизации" системы :-)А ее - при желании - тоже можно хранить в /usr/local :)
>а как же база данных установленных пакетов? ее же тоже надо удалить
>для "девственнизации" системы :-)ладно. уговорил, нужно ввести два раза rm :)))
но в любом случае логичность должна присутствовать.
>>а как же база данных установленных пакетов? ее же тоже надо удалить
>>для "девственнизации" системы :-)
>
>ладно. уговорил, нужно ввести два раза rm :)))
>но в любом случае логичность должна присутствовать.pkg_delete -f \* и максимум что останется - конфиги в etc.
в линукс, да.. логичности бы не помешало.
Читаю я коменты выше и недоумеваю - товариСчи, а вы хотя бы разобрались в вопросе или просто только бы чего умного ляпнуть? Если знаете английский то почитайте дружественный фак для начала, а потом ответы на большинство изложеных в комментах выше клише.
http://gobolinux.org/index.php?page=faq
http://gobolinux.org/index.php?page=doc/articles/clueless
>Читаю я коменты выше и недоумеваю - товариСчи, а вы хотя бы
>разобрались в вопросе или просто только бы чего умного ляпнуть?Они же сами в оном факе пишут -- "мы идиоты и не нужны":
In fact, it was motivated to fulfill the needs of users who prefer to install applications from the original source packages instead of relying on the distribution.
Так вот слакварь можно устроить из любого дистрибутива, вовсе необязательно для этого НЕ полагаться на ещё одно поделие, авторы которого не осилили ни FHS, ни управления софтом :-/
См., например, http://www.linux.kiev.ua/ru/docs/articles/ideal-sysadm-rpm/
Хотя ты Миша и простреленный в голову, но с этим твоим постом согласен полностью!FHS - в Линуксе это то за что надо держаться обеими руками и биться за него до смерти!
Если и это похерят - Линуксу конец ... правда я не верю что нормальные люди на это пойдут :)
Кстати всё сказанное не означает что FHS должен быть неизменным - всё меняется и он должен меняться. Эволюционно.
Интересно, а я бы попробовал.
Забавно посмотреть на вывод ldconfig
c
/Programs/OpenOffice/1.1.4 и,
/Programs/OpenOffice/2.0
ппц. принципы организации иерархии директорий это уже потаенное знание, требующее обсуждений, публикаций с толкованиями и альтернативные решения. потерялись знания предков, пока весело тащили линух на десктоп.от ГомоЛинух просто плакать хочется и умолять "госпади не приведи мне юзать ЭТО на производстве".
Гм... Совершенно невнятная идея. Такое впечатление, что люди придумали проблему, а потом ее решают. Если им так важно, чтобы можно было легко удалять программу, поставленную не из репозитория - checkinstall и аналоги в помощь. Не говоря о make uninstall... А если уж софт uninstall не поддерживает - ровно также он может записать любые файлы куда попало. Товарищ прицепился к паре рудиментов вроде /use/X11R6, а на остальное просто фантазия богатая. Ну лежит часть бинарников в /sbin, часть в /bin - дык и разделение там есть - на нужные руту и общие, и не особо принципиально это, вообще говоря... Их уродливые названия каталогов программ - это вообще нечто. Не знаю, кто как - но лично я это запоминать и набирать из командной строки не стремлюсь совершенно. Зато трехбуквенные стандартные названия, понимаете ли, устарели... Конечно, может, "домохозяйкам" это и удобно, но эффективной работе с системой точно не способствует.
Симлинки - это вообще бред какой-то. просто rm -R /Programs/SomeProg не пройдет - нужно еще поубивать все симлинки на удаленные файлы, то есть нужен-таки какой-то инструмент - дык и пусть он полностью удаляет софтину, чего ж проще? Тем более, что режим "удалить, но оставить конфиг" тоже никто не отменял, и реализовывать его как-то надо.Ну, там еще масса возражений может быть, но основное - люди пытаются решать несуществующие проблемы.
Для десктопа, не видел ничего удобнее системы установки/удаления программ, чем в мак ос. Было бы здорово, если бы такое сделали и для линукса, без гиморных зависимостей и прочих make uninstall, которые обычному пользователю не нужны, да и вряд ли он об этом знает. И знать ему не нужно.
Просто и по-человечески, перетащил программу мышкой куда тебе захочется и используешь.На серверах это все ни к чему, согласен.
>Просто и по-человечески, перетащил программу мышкой куда тебе захочется и используешь.По-человечески - это как есть сейчас, через пакетный менеджер. А "перетаскивать мышкой программы куда захочется" - верный путь к бардаку и вирусам, и большой шаг назад в деле достижения модульности, отслеживания зависимостей и актуальности библиотек и программ.
>>Просто и по-человечески, перетащил программу мышкой куда тебе захочется и используешь.
>
>По-человечески - это как есть сейчас, через пакетный менеджер. А "перетаскивать мышкой
>программы куда захочется" - верный путь к бардаку и вирусам, и
>большой шаг назад в деле достижения модульности, отслеживания зависимостей и актуальности
>библиотек и программ.Вы пробовали или предполагаете?
>Вы пробовали или предполагаете?Я - пробовал. А вы?
>>Вы пробовали или предполагаете?
>
>Я - пробовал. А вы?Дома у меня мак ос, на работе линукс. И ей богу, не понимаю, почему мне для установки например пиджина, необходимо доустановить еще кучу пакетов. А для установки Адиума (версия пиджин на маке), использующего ту же библиотеку что и пиджин, необходимо всего лишь перетащить приложение в Applications. Если мне необходимо удалить приложение, я перетаскиваю его в трэшкэн и мне не надо помнить о куче доустановленных пакетов в виде библиотек. По-моему, тут гораздо больше порядка, чем в линуксе с его депендсами. И более наглядно для пользователя, если мы уж начали говорить о контроле над системой.
Естественно это интересно для десктопа.
>Дома у меня мак ос, на работе линукс. И ей богу, не
>понимаю, почему мне для установки например пиджина, необходимо доустановить еще кучу
>пакетов.Ну например потому что пиджин эти пакеты использует. Кроме того, кто ВАС заставляет что-то доустанавливать? Этим должна заниматься система пакетного менеджмента.
>А для установки Адиума (версия пиджин на маке), использующего ту
>же библиотеку что и пиджин, необходимо всего лишь перетащить приложение в
>Applications.Устанавливаете таким же образом ещё одну программу, использующую ту-же библиотеку - и у Вас уже две копии одной и той же библиотеки. А в случае ошибки или уязвимости в библиотеке нужно будет обновлять обе. А иначе, предположим, - угонят аккаунт или при определённых обстоятельствах программа будет вылетать, что тоже не очень приятно.
>Если мне необходимо удалить приложение, я перетаскиваю его в трэшкэн
>и мне не надо помнить о куче доустановленных пакетов в виде
>библиотек.А в чём собственно проблема? Я набираю "aptitude remove пакет" и пакет удаляется со всеми пакетами, которые ему нужны были для работы, но больше не нужны другим пакетам. Если не нравится консоль, можно найти графическую оболочку (Synaptic вроде есть).
>По-моему, тут гораздо больше порядка, чем в линуксе с его
>депендсами.Вы не правы. Почему - уже объяснил в примере про две библиотеки.
Плюс к этому могу привести ещё аргументы:
1. Пользователь поставил куда-то программу, а теперь хочет её удалить, но не может вспомнить, куда он её поставил.
2. Программа для пиджина хочет установить новый скин или смайлы, но не может его найти, т.к. не знает, куда её поставил пользователь. А пользователь, опять таки, сам забыл, куда он её поставил.
3. Злой хакер Вася Пупкин дал пользователю протрояненую программу. Пользователь этого просто не заметил.
4. Одна из программ прописала модуль-сервер в автозагрузку, а пользователь перенёс программу в другое место, и теперь этот модуль не запускается при загрузке и программа не работает.>И более наглядно для пользователя, если мы уж начали говорить
>о контроле над системой.Более наглядно - открыть графический пакетный менеджер, по описанию найти нужную программу, выбрать её и нажать кнопку "установить". Или запустить пакетный менеджер и нажать кнопку "обновить систему". Или запустить пакетный менеджер, посмотреть список установленных программ, найти ненужную, отметить её и удалить.
Более наглядно для пользователя вообще работать с документами, и не вдаваться в то, что такое "файловая система". Многие макосники, кстати, я слышал, даже не знают что это такое! Уж не знаю анекдот ли это или нет...
>Естественно это интересно для десктопа.
Как я уже объяснил - не интереснее. И кроме того, чем десктоп принципиально отличается от сервера? И там и там есть операционная система и есть программы.
>не понимаю, почему мне для установки например пиджина, необходимо доустановить еще кучу
>пакетов.Потому что он не таскает этот код с собой.
>А для установки Адиума (версия пиджин на маке), использующего ту
>же библиотеку что и пиджин, необходимо всего лишь перетащить приложение в
>Applications.Библиотека откуда берётся? А знание, куда надо перетащить -- проще апта или сложнее?
>Если мне необходимо удалить приложение, я перетаскиваю его в трэшкэн
>и мне не надо помнить о куче доустановленных пакетов в виде
>библиотек.aptitude помнит, что пакет потащил, и при его сносе старается снести и лишнее (если оно никому ещё за прошедшее время не потребовалось).
>По-моему, тут гораздо больше порядка, чем в линуксе с его депендсами.
Только по-Вашему. В средневековье без электричества тоже было куда проще...
>И более наглядно для пользователя, если мы уж начали говорить
>о контроле над системой. Естественно это интересно для десктопа.Да, /ощущение/ контроля над системой софтом в .dmg, безусловно, приятнее.
Джобс и вообще такой же торговец ощущениями, как и Гейтс, только более талантливый. :)
>Дома у меня мак ос, на работе линукс. И ей богу, не
>понимаю, почему мне для установки например пиджина, необходимо доустановить еще кучу
>пакетов. А для установки Адиума (версия пиджин на маке), использующего ту
>же библиотеку что и пиджин, необходимо всего лишь перетащить приложение в
>Applications.Ой не надо про mox !!! Вот где бардак!!! Даже винда выглядит приличнее!!!
по верх старой доморощенной бсд накручены старые маковские каталоги, без всякой логики.
КОШМАР!!
Живите по POSIX - и будет Вам счастье!
Попробуй slax
http://www.slax.org
Авторы гоболинукса придумали сами себе проблему и теперь ее решают.Переименование рута в зеро придает этому дистрибутиву некую завершенность, как в старом анекдоте про расстрел жидов и велосипедистов.
От части верно, но проблему с разными версиями программ не написали как будут решать конкретно. Думаю никак, слишком накладно, а по началу туши свет. Не думаю что это того стоит, хотя и не мешало бы.
Есть проблеммы, или так или иначе возникнут в будущем! Запутанная она, не интуитивно понятная. Не читал скажите не разбирался, нет разобрался, но считаю не прозрачной не понятной. Считаю современные пакетные менеджеры перегруженными, особенно rpm. Нужно сделать так чтобы была возможность обходится без него (пакетного менеджера). gobolinux со своими ссылками это конечно страшно, еще более запутывает, и не эффективно. Но идея gobolinux, а также pc-bsd - будущее. При чем тут попахивает виндой или маком?... надо брать лучшее из всех OS. И не стоит фанатеть и следовать тупо заветам предкам (это касается иерархии файловой системы в Linux). В BSD правильно говорят, многое продуманее сделано, но linux прогрессирует сильнее, ускоряется. Мне например, и думаю большинству не жалко процессорного времени, и памяти (поскольку сегодня она дешевая), и места на НЖМД. проще посмотреть в папку с программами (неважно как будет папка называтся) и видеть что стоит допустим апач 2.1... и апач 2.2 и удалить старую версию, хотя для ленивых это может сделать пакетный менеджер.
Хотя тут есть пару камней, но думаю это можно решить.
1. Допустим программы используют одинаковые порты...
2. Программы используют одинаковые библиотеки...В общем надо новый стандарт иерархии файловой системы в Linux, Двигатся надо в сторону х64 битных систем... главное всё под GPL!!!
А может кому то лень? стал стар? кого то всё уже устраивает?
>Хотя тут есть пару камней, но думаю это можно решить.
>1. Допустим программы используют одинаковые порты...
>2. Программы используют одинаковые библиотеки...Это камни, возникающие на ровном месте из-за стремления "чтоб не как у других". Современные пакетные менеджеры решают эти задачи.
>В общем надо новый стандарт иерархии файловой системы в Linux, Двигатся надо
>в сторону х64 битных систем... главное всё под GPL!!!Да-да, и чтобы Вам на блюдечке всё это поднесли и уговаривали: "Ну пользуйся, ну посмотри какая удобная система! Ведь всё для тебя старались делали! И совершенно бесплатно!"
>А может кому то лень? стал стар? кого то всё уже устраивает?
Похоже, что кому-то лень изучить пакетный менеджер, этот кто-то слишком молод чтобы найти плюсы при таком большом количестве минусов, и его не устраивает работающее решение.
>Считаю современные пакетные менеджеры перегруженными, особенно rpmВ slackware или arch простые и понятные каждому менеджеры пакетов.
>И не стоит фанатеть и следовать тупо заветам предкам
Вот именно, вы наверное помните дос. То что относилось к операционке лежало в c:\dos, а закрытые программы устанавливались туда куда сами хотели. Не ужели вы думаете, что создатели unixa были такими тупыми, что решили всё разделить? Это новая категория мышления - человек, отличаетя от обезьяны тем, что пытается всё раскладывать по полочкам (причём его не сильно беспокоит, что иногда предмету не удаётся подобрать полочку или наоборот, что его можно положить сразу на несколько).
>В общем надо новый стандарт иерархии файловой системы в Linux. А может кому то лень? стал
>стар? кого то всё уже устраивает?В америке словом pine называют ёлку, кедр, сосну и все остальные хвойные деревья. Они пытаются сделать биологию user-friendly. Тем же самым какие-то люди занимаются в отношении linux. Уверен, что эти меры не пройдут (в качестве стандарта), поскольку здравый смысл рано или поздно одержит верх над тупизной.
В очередной раз понимаю, что всё уже придумано до нас и VMS рулит.
Там нету никаких позорных PATH-ов, а есть системные и пользовательские
таблицы команд и библиотек ;)
Так что раскладывать программы можно как угодно, хоть вдоль, хоть поперёк,
а хоть бы и вовсе крестиком - главное в нужной таблице всё зарегистрировать
Опередил меня предыдущий Аноним...
Хотел сказать, что, может быть, дело не в несовершенстве той или иной иерархии файлов в системе, а в том, что несовершенна сама идея иерархической организации? Когда-то изобретение древовидной файловой системы было прорывом, но, может быть, пора подумать об об организации файлов (в том числе -- программ и библиотек) в виде базы данных?
>но, может быть, пора подумать об об организации файлов (в том числе --
>программ и библиотек) в виде базы данных?Ну подумайте :)
PS: "и хде теперь ваша VMS?" ;)
>>но, может быть, пора подумать об об организации файлов (в том числе --
>>программ и библиотек) в виде базы данных?
>
>Ну подумайте :)
>
>PS: "и хде теперь ваша VMS?" ;)На своём прежнем месте надёжных промышленных систем.
http://h71000.www7.hp.com/servermatrix.html
HP пыталась после слияния с Compaq её похоронить, но влиятельные заказчики стукнули им по башке и HP её перенесла на Itanium.
>HP пыталась после слияния с Compaq её похоронить, но влиятельные заказчики стукнули
>им по башке и HP её перенесла на Itanium.hint: читается "Итаник"
>HP её перенесла на Itanium.Ага, и теперь хоронят вместе с ним :DDDD
Уже почти все модели с ним умерли - упокой их душу....
Проблема действительно существует?
Неявность распредение программ по bin и sbin мне кажется не очень веский аргумент для переделывания структуры ФС.
Про резервирование всех файлов программы уже писали (какая-то странная необходимость). Конфиги бэкапяться легко.Для домохозяек скрыть "ужос" структуры ФС можно на уровне менеджера файлов DE, с помощью виртуальной файловой системы, которая представит все каталоги в удобном и понятном виде, сгруппирует файлы/библиотеки, даст читаемые названия и т.п.
насчет opt не согласен, изаю его для прог со своим инсталлером (платный софт как правило)
Радетелям пакетных менеджеров задаю вопрос: вам не кажется, что пресловутые менеджеры в большинстве случаев не полностью выполняют своё предназначение?
Как они разруливают вопрос с организацией параллельной установки разных версий программ, если это не заложено при сборке пакета? Могут ли они восстановить или проверить целостность инсталляции? Слишком много полномочий передаётся мэнтейнеру. Пользователю остаётся лишь уповать на то, что мэнтэйнер "правильный" и не завалит систему, переписав половину /bin своими файлами.
>Радетелям пакетных менеджеров задаю вопрос: вам не кажется, что пресловутые менеджеры в
>большинстве случаев не полностью выполняют своё предназначение?Не-а. В подавляющем большинстве случаев они прекрасно справляются :)
>Как они разруливают вопрос с организацией параллельной установки разных версий программ,
>если это не заложено при сборке пакета?Если есть файловые конфликты (например, обе версии содержат usr/bin/softinka) -- то разве что ставить в разные корни (в rpm возможность relocation теоретически есть, практически пользоваться не доводилось -- и, кажется, должна быть разрешена, т.е. "заложена при сборке пакета").
>Могут ли они восстановить или проверить целостность инсталляции?
rpm -- издревле; с dpkg до недавних пор было сложнее (суммы не считались), но вроде и там дорабатывали.
>Слишком много полномочий передаётся мэнтейнеру.
Ему передаётся необходимое и достаточное количество полномочий: обладание компетенцией по сборке данной программы для данного дистрибутива.
>Пользователю остаётся лишь уповать на то, что мэнтэйнер "правильный"
>и не завалит систему, переписав половину /bin своими файлами.Во-первых, пользователю всегда приходится более или менее доверять другим: полный аудит *всего* кода, который исполняется на заданной системе -- как минимум нетривиальное занятие.
Во-вторых, у пользователя всегда есть выбор:
- кому доверять
- кому _не_ доверять
- сделать лучше самому и предложить вместоПричём эти "первые" и "вторые" _принципиально_ не зависят от ОС, хотя сложность выбора и трудоёмкость реализации, конечно, зависит.
Ээээ.... нахрена мне опен офис 1.4 если есть 2.0? :-) Почему в моей убунте нет такой проблемы, как у этих парней? Задолбали уже со своим анальным рабством...
Недостаток запихивания почти всех бинарников в /usr/bin, библиотек в /usr/lib - комп немного притормажывает, если зайти в них. Считаю, что программы лучше ставить в /opt/<имя пакета>/, при этом много каталогов в /opt создавать не стоит, например, лучше все kde поставить в /opt/kde. /usr/local, скорее всего, не нужно. Оконную систему лучше ставить в /opt/xorg или /usr/xorg, название каталога X11R6 часто не соответсвует версии системы x11 (x11r7). В /bin, /usr/bin лучше ставить только необходимые для системы программы. А вот procfs, /dev и sysfs можно вообще убрать из основного дерева, например, заменив на procfs:/, sysfs:/ и т. д. (можно сделать ссылки /proc -> procfs:/), т. к. проще будет инициализировать систему (например, не надо будет монтировать /dev, система будет загружаться и при отсутствии данных каталогов).
>Недостаток запихивания почти всех бинарников в /usr/bin, библиотек в /usr/lib - комп немного притормажывает, если зайти в них.Сканирование /usr/bin/ -- нечастая операция. Для программ практически вообще ненужная.
[skip]
> procfs:/
Мгм. И konqueror определить ядерным тредом? :]
> Сканирование /usr/bin/ -- нечастая операция. Для программ практически вообще ненужнаяА пользователя немного напрягает. В общем, одна из множества мелочей, которые ни на что не влияют, но от которых хотелось бы избавиться.
А как быть с x32 и x64 бинарниками?У меня есть */lib и */lib64,
x32 бинарники в /usr/bin/32
>А как быть с x32 и x64 бинарниками?
>
>У меня есть */lib и */lib64,
>x32 бинарники в /usr/bin/32Вас это беспокоит? Вы хотите об этом поговорить? :-)
Понятно что дела похо :(
>Понятно что дела похо :(Ну а как тут без костыля?
Правда 32 софта на 64 системах с каждым годом всё меньше ...
>> Сканирование /usr/bin/ -- нечастая операция. Для программ практически вообще ненужная
>
>А пользователя немного напрягает. В общем, одна из множества мелочей, которые ни
>на что не влияют, но от которых хотелось бы избавиться.Нафиг пользователю вообще в этот каталог заходить??? Чтобы кликнуть мышкой по бинарнику программки? Ну дык все нужное пользователю лежит в менюхах KDE, Gnome etc.
Что забыл пользователь в /usr/bin и, уж тем более, в /usr/lib? У него всё на рабочем столе в менюшках.
учите матчасть, зачем два раза rmrm -r /var/db/pkg /usr/local
согласен. в линуксах неразбираемая свалка. собственно это из-за зоопарка линуксов вокруг и отстуствие системной целостности.хороший пример FreeBSD: /usr и /etc для base, /usr/local и /usr/local/etc для стороннего софта из пакеджей и/или портов.
>согласен. в линуксах неразбираемая свалка. собственно это из-за зоопарка линуксов вокруг и
>отстуствие системной целостности.
>
>хороший пример FreeBSD: /usr и /etc для base, /usr/local и /usr/local/etc для
>стороннего софта из пакеджей и/или портов.Уфф, ничего против фряшников не имею, но они настолько ограничены рамками своей системы...
Ну сколько раз вам нужно повторять, что Linux не делится на base и пакаджи/порты? В большинстве Linux даже ядро является пакетом, поэтому такое деление не имеет смысла!
Помнится при установке Слаки некоторые пакеты помечались как required. И такие пакеты есть в любом дистре: kernel - это как минимум, можно еще предложить init в любой его инкарнации, если говорить о дистре, а не о LFS, где под init можем хоть /sbin/reboot предложить. Собственно это и есть с точки зрения фряхи /, /usr, /etc и т.д. Остальное (опять-таки при фряшном подходе) - /usr/local, /usr/local/etc и т.д.Но в общем и целом - каждому видней. И несовместимость разнообразных "ИМХО" не есть повод делить человечество на "дебилов" и "гуру", тем более принадлежность к данным категориям будет меняться на противоположную в каждом из "лагерей сторонников".
>Но в общем и целом - каждому видней.Да.
>И несовместимость разнообразных "ИМХО" не есть повод делить человечество на "дебилов"
>и "гуру", тем более принадлежность к данным категориям будет меняться на противоположную
>в каждом из "лагерей сторонников".Э, нет. Здесь помедленней.
Если человек врёт себе и другим, то он никак не "гура". Хотя может, и не "дебил", а просто соображать ещё не научился. Даже если со стажем в NN лет, как вот Андрей Вингородов.
А мнения и подходы действительно бывают разные, со своими плюсами и минусами в разных обстоятельствах. И ошибаемся мы все тоже каждый со своей частотой, но поскольку люди... то неизбежно. :)
>>согласен. в линуксах неразбираемая свалка. собственно это из-за зоопарка линуксов вокруг и
>>отстуствие системной целостности.
>>хороший пример FreeBSD: /usr и /etc для base, /usr/local и /usr/local/etc для
>>стороннего софта из пакеджей и/или портов.
>Уфф, ничего против фряшников не имею, но они настолько ограничены рамками своей
>системы...А я против таких имею -- бо зело любят вещать ерунду вроде "в линуксах неразбираемая свалка" и далее по тексту, которую от такого же умника услышал, с ушей не снял (вилки нет, шапку с четырьмя козырьками тоже ещё не заработал) -- и радостно дальше транслировать без попытки обдумать и тем более проверить.
Какая нафиг "системная целостность" при отсутствии ресурсов на бранчи портов? :(
>Ну сколько раз вам нужно повторять, что Linux не делится на base
>и пакаджи/порты? В большинстве Linux даже ядро является пакетом, поэтому такое
>деление не имеет смысла!При этом выделить компактную базовую систему в приличных случаях вполне возможно. Только содержать она будет не компилятор, а менеджер пакетов.
При всем этом они забыли, что юникс это изначально многопользовательская система.
и каждый юзер имел домашний каталог. И если ставилась более-менее нужная всем программа- она ставилась в /usr/local. А если конкретного васю пупкина не устраивал офис-1, то ему ставился офис-2 в /home/vpupkin/[opt..bin..etc..] - эту иерархию никто не отменял и все разруливалось короткими путями. А еще во вменяемой программе должен быть вариант make uninstall. Ну или при работе менеджеров пакетов это уже проблема дистростроителя. Программы ставить и сносить сотнями в день - это вариант знакомства с системой, при нормальной ежедневной осознанной работе это уже не надо.
>При всем этом они забыли, что юникс это изначально многопользовательская система.И ещё все не хотят вспоминать, что создатели UNIX ещё долго после 70-го, и после 92-го, развивали свою ОС, и решения для Plan9 в очень многих местах радикально отличны от первоначальных решений в UNIX, в том числе и для иерархии каталогов, линков на файлы и способов монтирования. Найдены гораздо более простые и практичные решения, чем те, которые юзают и заново изобретают линуксологи. А уж на маздайных ламеров смотреть тошно, как они прямо болеют без диска C:\\, их хлебом не корми, только дай завести какое-нибудь чудо вроде "Программные Файлы" или запихать три строчки из /etc/fstab в OpenXML(tm)