форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Проблемы организации иерархии файловой системы в L..."

Сообщение от opennews on 19-Авг-08, 10:36

В материале "GoboLinux and Replacing the FSH (http://osnews.com/story/20195/GoboLinux_and_Replacing_the_FSH)" представлены результаты обсуждения (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 Новость: http://www.opennet.dev/opennews/art.shtml?num=17451

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Spike on 19-Авг-08, 10:36

Я в линуксе не так давно (3-й год ) меня поначалу напрягало то что непонятно что где находится, а сейчас я даже вижу свои плюсы такого распределения файлов...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от User294 (??) on 19-Авг-08, 18:49
	+1, в линуксе все логично распихано, более того даже в конце концов поизобретав велосипеды задолбался и честно спер иерархию в итоге. X:\Program Files <-> /usr/bin X:\Documents and Settings\user <-> /home/user %WINDIR%\* и %WINDIR%\*SYSTEM* <-> /bin, /sbin и каталоги библиотек. ну и в таком духе... Если в традиционной FHS иерархии сразу понятно - вон там программы, вон там shared данные программ, вон там логи а вон там конфигурация. Использование 1 папки на программу... хм... каюсь, грешен, иногда и НЕКОТОРЫЕ сервисы я так люблю выносить в отдельные папки.Это нужно для того чтобы было проще держать интенсивно используемые и критичные сервисы под вниманием.Но если ВСЕ программы так будут распиханы, это чем-то напоминает подход... времен MS-DOS.Когда программы в силу отсутствия стандартных мест просто гадили в свои папки.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 19-Авг-08, 10:40

>неявность критериев распределения программ по директориям 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 очень правильная мысля для отделения прог, собранных из исходников и искать по папкам программ неудобно, неужели виндузятники прибежали и решили сделать такую же гадость как в винде?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от GateKeeper (??) on 19-Авг-08, 11:47
	>и искать по папкам программ неудобно, неужели виндузятники прибежали и решили сделать >такую же гадость как в винде? Говорить "папка" - есть мышление виндузятника, не понимающего, почему этот термин логически никак не применим к понятию, которое он в это слово вкладывает. Правильно говорить "каталог".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от avatar (??) on 19-Авг-08, 12:27
	Ха.ХА. Есть к чему придратся. Да, это сильно посуществу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	93. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от asv (??) on 19-Авг-08, 21:48
	правильно говорить "директория".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	110. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от GateKeeper (??) on 20-Авг-08, 09:04
	Слово "directory" переводится дословно как "справочник", что очень близко к "каталог". Слово же "директория" существует в языке лишь на правах слов "рутер", "файрвол", "свитч".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	111. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 20-Авг-08, 09:15
	>Слово "directory" переводится дословно как "справочник", что очень близко к "каталог". Слово >же "директория" существует в языке лишь на правах слов "рутер", "файрвол", >"свитч". Поддерживаю. Такие слова допустимы в неформальном разговоре с коллегами, но вообще лучше употреблять слова "каталог", "маршрутизатор", "пакетный фильтр", "коммутатор" или "Ethernet-коммутатор".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	141. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от SKeeper on 21-Авг-08, 10:17
	Есть обоснование? По-моему лучше уж использовать транскрипции с буржуйского для таких терминов, тогда нет неопределенности в том, что имеется в виду.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	142. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 21-Авг-08, 10:23
	>Есть обоснование? По-моему лучше уж использовать транскрипции с буржуйского для таких терминов, тогда нет неопределенности в том, что имеется в виду. Ну а где неопределённсть в названных русскоязычных терминах? А у вас обоснование есть? Может вообще лучше на английском разговаривать? Я люблю свой язык и не использую НЕОПРАВДАННЫЕ англоязычные термины.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	146. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от amkir on 21-Авг-08, 11:06
	>А у вас обоснование есть? Может вообще лучше на английском разговаривать? Я >люблю свой язык и не использую НЕОПРАВДАННЫЕ англоязычные термины. Вы о чём, коллега? Названные Вами слова -- "каталог", "маршрутизатор", "пакетный фильтр", "коммутатор" -- тоже отнюдь не русские. Точно такая же калька с иностранного (стыдливо именуемая "заимствованием"), только сделанная на пару-тройку веков раньше. Что, возраст заимствования есть "ОПРАВДАНИЕ" его применению?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	148. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 21-Авг-08, 12:05
	>>А у вас обоснование есть? Может вообще лучше на английском разговаривать? Я >>люблю свой язык и не использую НЕОПРАВДАННЫЕ англоязычные термины. > >Вы о чём, коллега? Названные Вами слова -- "каталог", "маршрутизатор", "пакетный фильтр", >"коммутатор" -- тоже отнюдь не русские. Точно такая же калька с >иностранного (стыдливо именуемая "заимствованием"), только сделанная на пару-тройку веков раньше. > >Что, возраст заимствования есть "ОПРАВДАНИЕ" его применению? Да, возраст заимствование - оправдание. Если слово с похожим смыслом уже есть в языке, пусть тоже заимствованное, зачем заимствовать ещё одно? Неужели словам "рутер", "свич" и "хост" нет адекватных эквивалентов в русском языке? Есть, поэтому повторное заимствование считаю нецелесообразным.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	150. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от SKeeper on 21-Авг-08, 12:37
	>Ну а где неопределённсть в названных русскоязычных терминах? Неопределенность в том, что у одного термина несколько названий. Когда я только начинал осваивать профессию программиста и сисадмина, то я долго путался в роутерах/маршрутизаторах, коммутаторах/свичах. >А у вас обоснование есть? Может вообще лучше на английском разговаривать? Я >люблю свой язык и не использую НЕОПРАВДАННЫЕ англоязычные термины. Раньше, до того как выбрал и полюбил профессию программиста, более сильного врага "неоправданных заимствований" чем я сложно было найти. Но начав в большом количестве читать англоязычную литературу (не потому что русский разлюбил, а потому что нет русскоязычных аналогов) я несколько поменял свое мнение. Я в предыдущем своем посте несколько невнятно выразился, но в целом я имел ввиду следующее: Когда уже появился _устоявшийся в профессиональной среде_ русскоязычный термин (как маршрутизатор), то мне вообще пофигу кто какое слово упоминает. Но когда вводится _новый_ термин, то лучше использовать транскрипцию нежели придумывать дублирующую сущность.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	151. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 21-Авг-08, 12:59
	>Неопределенность в том, что у одного термина несколько названий. Когда я только >начинал осваивать профессию программиста и сисадмина, то я долго путался в >роутерах/маршрутизаторах, коммутаторах/свичах. Думаю, что путались Вы именно из-за любителей неоправданно внедрять англицизмы. >Раньше, до того как выбрал и полюбил профессию программиста, более сильного врага >"неоправданных заимствований" чем я сложно было найти. Но начав в большом >количестве читать англоязычную литературу (не потому что русский разлюбил, а потому >что нет русскоязычных аналогов) я несколько поменял свое мнение. Ну этим Вы просто признались, что читая английскую литературу Вы начинали немножко думать по-английски. Это нормально, когда много читаешь на чужом языке. Но это не оправдывает замусоривание русского языка. >Я в предыдущем своем посте несколько невнятно выразился, но в целом я >имел ввиду следующее: >Когда уже появился _устоявшийся в профессиональной среде_ русскоязычный термин (как маршрутизатор), то >мне вообще пофигу кто какое слово упоминает. Но когда вводится _новый_ >термин, то лучше использовать транскрипцию нежели придумывать дублирующую сущность. Я бы сказал не просто _новый_ термин, а термин, которому трудно подобрать русскоязычный аналог. Делается это просто - нужно заглянуть в словарь, и если там найдётся подходящее по смыслу слово, то использовать нужно его. С другой стороны, не стоит искусственно придумывать называния для терминов, не имеющих адекватного перевода. Беда лишь в том, что граница эта часто нечёткая...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	115. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от gegMOPO4 on 20-Авг-08, 11:24
	«Директория» — это из истории Украины начала XX века. Устоявшийся же в русскоязычной специализированной литературе перевод английского термина «directory» — «каталог».
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	126. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от uldus (ok) on 20-Авг-08, 15:01
	>«Директория» — это из истории Украины начала XX века. Устоявшийся же в >русскоязычной специализированной литературе перевод английского термина «directory» — «каталог». Помнится еще в 80-х годах в учебниках, словарях и книгах связанных с ЭВМ использовался именно термин "директория" и уже потом полезли каталоги и папки.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от xxx (??) on 19-Авг-08, 12:55
	>согласен только с /usr/X11R6 >/opt удобен для программ не из репозитария со своими инсталлерами >/usr/local очень правильная мысля для отделения прог, собранных из исходников /usr/X11R6 конечно рудимент, но множеству старых программ этот каталог требуется, поэтому символическую ссылку на него держать думаю стоит. Вообще согласен, что главная проблема - это большая сложность организации совместного использования программ различных версий. Огромное количество зависимостей тоже проблема при обновлениях и т. д. Поэтому как сделано в PC-BSD иногда бывает удобно. Но с другой стороны, администрировать и поддерживать в актуальном состоянии удобнее именно существующую иерархию. Вспоминаю M$ Windows, когда находят баг в библиотеке работающей с BMP рисунками, ты ставишь заплатку на системную библиотеку. И вроде всё хорошо и все счастливы, но ведь каждый пионер, наровит засунуть в дистрибутив своей программы копию этой библиотеки и использовать именно её. Поэтому в *BSD/Linux мне такого не надо, по крайней мере как стандарт.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от uldus (ok) on 19-Авг-08, 15:13
	>Все очень даже явно - в sbin программы, которые имеет смысл запускать >только от админа C /bin и /usr/bin теже грабли. Проблема в том, что в разных дистрибутивах разные критерии отнесения программ к категории админских и минимально-необходимых. Где-то приходится писать /bin/ping, где-то /sbin/ping, где-то /usr/bin/ping, а где-то /usr/sbin/ping.  Прописывать в скриптах полные пути - одно мучение.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 19-Авг-08, 17:05
	>C /bin и /usr/bin теже грабли. Проблема в том, что в разных >дистрибутивах разные критерии отнесения программ к категории админских и минимально-необходимых. Изначально в /bin лежали статически слинкованные утилиты, а в /usr/bin - динамически. При нормальной работе используются программы из /usr/bin. А в аварийной ситуации, когда повреждены разделы /var или /usr, используются программы из /bin. В bin лежат программы, не затрагивающие настройки системы. В sbin - изменяющие, в том числе доступные остальным пользователям, например passwd.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	92. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от User294 (??) on 19-Авг-08, 21:29
	>такую же гадость как в винде? В винде от нее пытаются уйти в сторону того что нынче в линуксах.То есть, майкрософт всеми силами пытается заставить авторов программ гадить не в свою папку а в диру с юзерским профайлом.В висте гайки подтянули - писать в каталог program files стало тупо нельзя.Все записи редиректятся в виртуальный говноотстойник (крайне костыльный и горбатый аналог /usr/share получается).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от prapor (??) on 19-Авг-08, 10:46

IMHO, проблема несколько надуманная. Никогда не видел чтобы выполняли резервное копирование бинарей программ. Разве что при полном резервировании системы."Выделение всех файлов одной программы" не нужно - нужны только конфиги и данные - они лежат в четко указанных местах. Точно так же и /opt ни разу не устрела, вместе с /usr/local - ими часто пользуются для специфического софта. Если же рассматривается десктопное применение - автору лучше не изобретать велосипед с квадратными колесами и сферической рамой. Все равно пользователю за пределами $HOME реально ничего не видно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от oops on 19-Авг-08, 14:00
	>IMHO, проблема несколько надуманная. Никогда не видел чтобы выполняли резервное копирование бинарей >программ. Разве что при полном резервировании системы."Выделение всех файлов одной программы" >не нужно - нужны только конфиги и данные - они лежат >в четко указанных местах. Все гораздо проще: Спросить у пакетного менеджера содержимое пакета.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от uldus (ok) on 19-Авг-08, 15:27
	>не нужно - нужны только конфиги и данные - они лежат >в четко указанных местах. Вы правда не видели программ с конфигами в /var/lib/name/ и с данными в /usr/lib/name/ ? Посмотрите, что rpm -q -a -c выдаст.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 19-Авг-08, 15:51
	>>не нужно - нужны только конфиги и данные - они лежат >>в четко указанных местах. > >Вы правда не видели программ с конфигами в /var/lib/name/ и с данными >в /usr/lib/name/ ? >Посмотрите, что rpm -q -a -c выдаст. Это проблема отдельных пакетов, отдельных мэйнтейнеров этих пакетов и отдельных пользователей, которым нужен такой пакет. В правильных системах с правильными пакетами и правильными мэйнтейнерами всё лежит в правильных местах.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	94. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от uldus (ok) on 19-Авг-08, 21:59
	>Это проблема отдельных пакетов, отдельных мэйнтейнеров этих пакетов и отдельных пользователей, которым >нужен такой пакет. В правильных системах с правильными пакетами и правильными >мэйнтейнерами всё лежит в правильных местах. Это не проблема мелких пакетов, а общая тенденция все сваливать в кучу. Яркий тому пример, я каждый раз плююсь выискивая в fedora и debian конфиг в котором описаны правила автомонитория.  Знайте где он ? В /usr/share. А конфиги gconf в /var/lib как вам ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	103. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от prapor (??) on 20-Авг-08, 00:26
	> каждый раз плююсь выискивая в fedora и debian конфиг в котором описаны правила автомонитория Авто- чего?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	106. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от oops on 20-Авг-08, 05:44
	>>Это проблема отдельных пакетов, отдельных мэйнтейнеров этих пакетов и отдельных пользователей, которым >>нужен такой пакет. В правильных системах с правильными пакетами и правильными >>мэйнтейнерами всё лежит в правильных местах. > >Это не проблема мелких пакетов, а общая тенденция все сваливать в кучу. >Яркий тому пример, я каждый раз плююсь выискивая в fedora и >debian конфиг в котором описаны правила автомонитория.  Знайте где он >? В /usr/share. А конфиги gconf в /var/lib как вам ? Значит что-то с головой у дистростроителей. Почему-то на фряхе я всегда могу сказать pkg_create -b и быть уверенным, что установленный софт снова завернется в пакет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	133. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от User294 (??) on 20-Авг-08, 18:47
	>debian конфиг в котором описаны правила автомонитория.   А нельзя ли уточнить о чем вы?Название пакета в студию, вместе с путем к конфигу. Вот честно - не врубаюсь что имелось в виду под "правила автомонитория".Авто?Монитория?Эээ... а монитория чего?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	143. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от SKeeper on 21-Авг-08, 10:25
	Ну я думаю этот чудный товарищ имеет ввиду таки автомонтирование. Только не ясно что конкретно он имеет ввиду. В общем по-моему бред и провокация :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	144. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 21-Авг-08, 10:30
	>Ну я думаю этот чудный товарищ имеет ввиду таки автомонтирование. Только не >ясно что конкретно он имеет ввиду. В общем по-моему бред и >провокация :) Нет, это правила втомонитория. И он каждый раз плюётся, выискивая их :) Я после установки пакета могу посмотреть список файлов, которые он установил. Как правило, я очень быстро нахожу то, что мне нужно. В том числе легко находятся установленные страницы руководств, конфиги, исполняемые файлы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	77. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от evs21 on 19-Авг-08, 19:34
	>Вы правда не видели программ с конфигами в /var/lib/name/ и с данными >в /usr/lib/name/ ? >Посмотрите, что rpm -q -a -c выдаст. +1! в последнее время все больше и больше пакетов, разработчики которых мягко говоря плохо представляют и не понимают куда что надо класть... примеров море! причем в их числе много известных широкоиспользуемых пакетов. Вот хотя бы MySQL... интересно каким боком /var/lib/ относится к базам данных?.. приметор море!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	105. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Antrew (??) on 20-Авг-08, 02:59
	Вообще-то именно в /var/lib/mysql и место файлам данных MySQL. /var/lib/<program_name> специально для этого и существует. Другое дело, если база у вас серьезная и большая - никто не запрещает вынести ее в /d01 /d02 и т.п. А большинству юзеров это не надо, потому и /var/lib/mysql.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	145. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от SKeeper on 21-Авг-08, 10:45
	>>Вы правда не видели программ с конфигами в /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/ - Информация о состоянии. Постоянные данные, изменяемые программами в процессе работы (например, базы данных, метаданные пакетного менеджера и др.)"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от www2 (??) on 19-Авг-08, 10:52

Надо же! Придумали "гениальную" идею, а затем вручили ей костыли симлинков. Может проблема в том, что идея далеко не гениальная?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от port on 19-Авг-08, 12:21
	а головой подумать и самостоятельно поискать ответ слабо? они использовали линки как вынужденую меру, а не как фичу. RTFM.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 15:46
	>а головой подумать и самостоятельно поискать ответ слабо? они использовали линки как >вынужденую меру, а не как фичу. Мне вот тоже кажется, что они использовали линки как вынужденную меру для подпорки своего ненужного изобретения, которое происходит из систем с безмозглым управлением ПО (и неумения студента-араба собрать пакет и договориться с сисадмином университетского тазика, чтоб его поставили/обновили). В приличных системах и впрямь можно спросить пакетный менеджер о составе пакета.  А ещё в приличных системах не хранят конфигурацию в /var/lib.  Остальное же "избирательно бэкапить" смысла нет, поскольку проще apt-get reinstall пакет. >RTFM. RTFM что?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от csdoc (ok) on 19-Авг-08, 16:54
	> А ещё в приличных системах не хранят конфигурацию в /var/lib однако, конфиги BIND`а - ALT Linux хранит в /var/lib/bind/etc/
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 19-Авг-08, 16:58
	>> А ещё в приличных системах не хранят конфигурацию в /var/lib > >однако, конфиги BIND`а - ALT Linux хранит в /var/lib/bind/etc/ Наверняка они там хранятся по вполне объяснимой причине - bind запускается в chroot'е. В var хранятся журнальные файлы, базы данных, DNS-зоны (чем не база данных?), веб-страницы. Всё это не является настройками, поэтому и лежит там.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	95. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от uldus (ok) on 19-Авг-08, 22:04
	>В var хранятся журнальные файлы, базы данных, DNS-зоны (чем не база данных?), >веб-страницы. Всё это не является настройками, поэтому и лежит там. Да уж, генеальная идея положить БД рядом с логами, при классическом отдельном монтировании /var есть неплохой шанс, что при каком-нибудь флуде логи забьют раздел и развалят базу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	96. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от csdoc (ok) on 19-Авг-08, 22:24
	> Да уж, генеальная идея положить БД рядом с логами, при классическом отдельном > монтировании /var есть неплохой шанс, что при каком-нибудь флуде логи забьют > раздел и развалят базу. причина этих проблем не в том, что базы данных лежат на одном разделе вместе с логами, причина проблем в том, что логи могут неконтролировано расти и занять все свободное место. (то же самое будет и при наличии всей файловой системы внутри одного физического раздела) workaround: вынести /var/log на отдельный раздел. (причем, возможность такого workaround`а в случае проблем - еще один громадный плюс традиционной файловой системы UNIX/Linux). более желательный solution: устранить причину проблем (неконтролируемый рост лог-файлов).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	100. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 23:19
	>Да уж, генеальная идея положить БД рядом с логами, при классическом отдельном >монтировании /var есть неплохой шанс, что при каком-нибудь флуде логи забьют >раздел и развалят базу. "Если вы такие умные, то почему строем не ходите?" -- в смысле монтируйте себе /var/lib и /var/log отдельными ФС и будет вам щастье. Не надо валить на пакаджеров и "классическое монтирование" проблемы между локалстулом и локалкейбордом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	104. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Dmitri (??) on 20-Авг-08, 01:13
	>>В var хранятся журнальные файлы, базы данных, DNS-зоны (чем не база данных?), >>веб-страницы. Всё это не является настройками, поэтому и лежит там. > >Да уж, генеальная идея положить БД рядом с логами, при классическом отдельном >монтировании /var есть неплохой шанс, что при каком-нибудь флуде логи забьют >раздел и развалят базу. Серьезные базы данных там не хранятся. СУБД хранит свои файлы на RAW разделах (хотя алтернативная возможность есть - в продакшене таким пользоваться нельзя). Поэтому при флуде `сломается` база данных нисколько не страшнее, чем то что при флуде некуда будет писать логи.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 17:16
	>> А ещё в приличных системах не хранят конфигурацию в /var/lib >однако, конфиги BIND`а - ALT Linux хранит в /var/lib/bind/etc/ Да, согласен -- равно как и других чрутизированных сервисов.  На основные (вроде named.conf) может быть симлинк из традиционного места в /etc, но это скорее хинт для человека, чем машиноисполняемое указание. Интересно, возможно ли случай с чрутами привести к приличному... :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 19-Авг-08, 17:25
	>Да, согласен -- равно как и других чрутизированных сервисов.  На основные >(вроде named.conf) может быть симлинк из традиционного места в /etc, но >это скорее хинт для человека, чем машиноисполняемое указание. > >Интересно, возможно ли случай с чрутами привести к приличному... :-) Мэйнтэйнеры ALT Linux подтянулись :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от csdoc (ok) on 19-Авг-08, 19:03
	>>> А ещё в приличных системах не хранят конфигурацию в /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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 19:25
	>в других системах bind может быть как chrooted так и не chrooted, >в этом случае /etc/named.conf - это не симлинк, а настоящий файл. Это понятно, просто мне лично системы, где bind до сих пор по умолчанию не в чруте, априори неинтересны/неправильны. >кроме того, как быть с тем, что "chroot is not and never >has been a security tool" ? Наш security officer замечен в симпатии к пустым readonly чрутам, а также чрутам без бинарников с suid/sgid, в которых код выполняется с уже пониженными после запуска привилегиями; смею заверить, что в таких случаях chroot -- это достаточно серьёзное дополнительное препятствие.  Хоть и не панацея, как и контейнеры. Но это не о том...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 19-Авг-08, 20:11
	Немного вернусь назад. То, что программы, помещённые в chroot не вписываются в иерархию пактов доказывает лишь то, что chroot либо изначально не предназначен для защиты демонов, либо просто неправильно сделан. Для защиты сервисов было бы разумнее сделать специальное средство, работающее на уровне ядра, которое изолировало бы определённый процесс доступом только к определённым файлам. Нечто вроде acl для каждого из сервисов, сюда же можно было бы добавить отдельные настройки фаерволла. Но всё это уже медленно переходит в идею паравиртуализации. Мне кажется, что в настоящее вреям именно паравиртуализация - самое лучшее средство защиты сервисов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	84. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 20:18
	>Мне кажется, что в настоящее вреям именно паравиртуализация - самое лучшее средство >защиты сервисов. На практике мне тоже так кажется, но и из чрутов не вытаскиваю...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	89. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от csdoc (ok) on 19-Авг-08, 21:01
	> То, что программы, помещённые в 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 кажется более оптимальным решением.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	99. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 23:13
	>делать каждому демону свой собственный контейнер - это приведет >к увеличению сложности системы и усложнит администрирование По крайней мере с некоторыми типами контейнеров возможно в рамках одного корня организовать разные контексты -- Петя Савельев в RADLinux когда-то так делал на vserver (эмбедщина по сути).  Насколько качественно изолирует -- не скажу, не всматривался. >особенно, если какие-то демоны должны будут взаимодействовать между собой. >и там останется только единственное средство для IPC - стек tcp/ip протоколов? Нуу ещё бывает shm и вообще-то сокеты можно mount --bind, но это всё работа пинцетом. >поэтому на первый и на второй взгляд SELinux кажется более оптимальным решением. Когда работает. :)  Задачи бывают разные, для многих куда проще сделать полупустой контейнер без лишних привилегированных бинарей, чем пытаться добить политику.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	98. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от User294 (??) on 19-Авг-08, 23:11
	>Интересно, возможно ли случай с чрутами привести к приличному... :-) По моему это одно из немногих мест где вариант с "1 каталог на программу" имеет право на жизнь.Вот что-что а в чрут потом такое запихивать намного удобнее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	101. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 23:21
	>>Интересно, возможно ли случай с чрутами привести к приличному... :-) >По моему это одно из немногих мест где вариант с "1 каталог >на программу" имеет право на жизнь.Вот что-что а в чрут потом >такое запихивать намного удобнее. Так чрут в любом разе (в штатном альте, по крайней мере) один на программу.  Причём есть тулза для автоматического поддержания -- update_chrooted(8) из пакета chrooted.  Довольно занятная, хоть и простая.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	153. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от fi (ok) on 22-Авг-08, 00:25
	To есть 'named' будет там же? под chroot? тогда прощай безопастность ;))) Изначально /var/lib/<name> задумывалось как отдельного места для пакета на /var, пусть оно так и будет. В принципе, для данных есть /srv/<name> , тут и надо разворачивать базы данных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	154. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от csdoc (ok) on 22-Авг-08, 00:39
	>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-файлы он не испортит
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	157. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 22-Авг-08, 14:09
	>наверное поэтому в RHEL named вынесли в отдельный каталог /var/named Ой, а давно /вынесли/-то?  Я вот думаю, что это просто ещё одна окаменелость в RHEL.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	158. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от csdoc (ok) on 22-Авг-08, 14:29
	>> в 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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	159. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 22-Авг-08, 14:37
	>>> в 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@ пужать, как из отпуска вернётся. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	160. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от csdoc (ok) on 22-Авг-08, 15:09
	>>>> в 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 станет приличной системой ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	136. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Serega (??) on 20-Авг-08, 23:20
	мб хранить конфиги в /etc а chroot-каталог создавать перед запуском демона? просто копировать конфиг из /etc в /var/lib/bind/etc. Я так понимаю он его не перечитывает в процессе работы?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 19-Авг-08, 10:57

Я за распределение программ по своим каталогам :) Только не надо делать симлинки на всё и вся. Возможен более гибкий подход, тока он ещё не придуман :) "Всё гениальное просто"

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Volodymyr Lisivka on 19-Авг-08, 16:11
	>Я за распределение программ по своим каталогам :) >Только не надо делать симлинки на всё и вся. >Возможен более гибкий подход, тока он ещё не придуман :) "Всё гениальное >просто" Если у тебя система на rpm/dpkg, то заходишь в mc в #rpms или #dpkg, и видиш каждую програму в отдельном каталоге. В чём проблема то?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от fank on 19-Авг-08, 11:00

что-то мне это напоминает.... а как теперь бинари запускать из комстроки? PATH раздуется до невероятных размеров?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Painbringer on 19-Авг-08, 11:04
	так они ж пишут у них там милиарды симлинков на все случаи жизни. вобщем очередной костыль имхо
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от fank on 19-Авг-08, 11:01

насколько я понимаю, бэкап пакета - это сохранение пакета и его конфигов чем плох полный бэкап /etc

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Black_Angel on 19-Авг-08, 11:30
	ценность в основном имеют конфиги. для бекапов пакетов есть специальные иинструменты. в Gentoo например есть quickpkg gcc. Собранный и установленный gcc соберется в tar.bz2 + гентушные примочки, но проигнорирует конфиги :) мухи отдельно. котлеты отдельно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Krivoy (??) on 19-Авг-08, 11:13

Мндяяяяяя... Как то услышал - "Любое сокращение штата на предприятии замысливается для его увеличения" Тут файл+ссылка преподносится как наведение прядка? Чёт сомневаюсь...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от gegMOPO4 on 19-Авг-08, 11:21

s/директория/каталог/g

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "OpenNews: Проблемы организации иерархии файловой системы в L..."

Сообщение от iZEN (ok) on 19-Авг-08, 11:53

Каждое приложение должно иметь свою виртуальную структуру каталогов, в которой оно хочет иметь присутствие. Для примера: /Program1 |-bin |-lib |-doc |-etc Всё это отображается на реальную файловую систему, например в такую: /usr/local |-bin |-lib |-doc |-etc При этом облегчается задача деинсталлятора — он просто удаляет виртуальную структуру каталогов приложения и всё! Что касается разделяемых библиотек, то необходимо придумать механизм "обобществления" виртуальных подкаталогов /lib установленных приложений, подсчёт ссылок на нужные библиотеки, в том числе на зацикленных графах и т.д. При удалении приложений с разделяемыми библиотеками вопросы нужности/ненужности библиотек должны решаться. Версионность библиотек должна быть совмещена с их именем в метаданных виртуальной системы каталогов, так как виртуальные каталоги подходят для хранения различных версий библиотек, файлы которых имеют одно и то же имя.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от Я (??) on 19-Авг-08, 12:08
	Дык, что-то такое они и хотят сделать. Вот только думается мне, что решать эту задачу нужно не на уровне ОС и ссылок, а на уровне ФС.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от RNZ (ok) on 19-Авг-08, 12:14
	Подобное предлагал и передлагаю сделать: http://gentoo.ru/node/4212
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от ahel on 19-Авг-08, 13:19
	Идея интересная, даже лучше, чем в Гобо. Ибо в Гобо попахивает Виндузятиной с их Программы систем и т.д., пусть Кесарю кесарево, а Богу Божье. Но по мне - так лучше четкая стандартизация, хотя на десктопах было бы нужнее, т.к. пользователю нужно постоянно инсталлировать, деинсталлировать и т.д.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от alexxy on 19-Авг-08, 13:25
	про данный изврат я уже писал на gentoo.ru оно не надо обычная юниксовая иерархия проще и понятнее не надо городить огород с сылками черезпопными ид каталогов и тд. Если тебе это нраавится то юзай но не надо другим навязывать
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	113. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от RNZ (ok) on 20-Авг-08, 10:51
	Это ты своё мнение другим не навязывай. Ссылки в предложенной идее - рудимент для совместимости, от которого в перспективе стоит вообще избавиться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	119. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от Michael Shigorin (ok) on 20-Авг-08, 11:47
	>рудимент для совместимости, от которого в перспективе стоит вообще избавиться. Ну-ну.  MS вот от 16-битной совместимости не может избавиться. Безумству молодых, сильных и впечатлительных поём мы кругом марш...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	120. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от RNZ (ok) on 20-Авг-08, 11:57
	Нужно понимать что сказанное соотносительно предложеному, а на вообще в целом. А опус о молодых приберегите для юнцов...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	147. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от SKeeper on 21-Авг-08, 11:10
	>Подобное предлагал и передлагаю сделать: >http://gentoo.ru/node/4212 Почитал и поддерживаю void. Хватает нормальных менеджеров пакетов, если нужно несколько версий одной программы (тестеру видимо), то хватит prefix, ну там chroot накрайняк.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Larin (??) on 19-Авг-08, 11:53

на самом деле проблема есть. в линухе с организацией файлов бардак.(хотя думаю от дистриба зависит). во фре, например, софт ставиться в /usr/local/ а там, /usr/local/etc, /usr/local/bin  и т.д. что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local все просто и логично.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 15:45
	>на самом деле проблема есть. в линухе с организацией файлов бардак.(хотя думаю >от дистриба зависит). >во фре, например, софт ставиться в /usr/local/ Вы бы всё-таки перестали попугаить эту ерунду.  "В линуксе" с организацией файлов бардака как раз на порядок меньше, чем во фре: в /usr/local собранное _локальным_ администратором, в /usr -- установленное системно при помощи средств управления ПО. Как во фре предлагаете различать собранное из портов и руками из тарбола, который в портах отсутствует?  В /opt ставить? ;-) > что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local > все просто и логично. ...для очень нужной задачи "получить никому не нужную голую систему".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 19-Авг-08, 16:00
	>>на самом деле проблема есть. в линухе с организацией файлов бардак. Бардака нет. В системе, где всё - пакет, и даже ядро можно обновить пакетом, не имеет смысла искусственно делить каталоги на системные и каталоги для прикладных программ. >> что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local >> все просто и логично. >...для очень нужной задачи "получить никому не нужную голую систему". Голая FreeBSD может роутить пакеты и быть фаерволлом, только преимущество "получить девственно чистую систему" мне кажется весьма сомнительным.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Аноним (??) on 19-Авг-08, 19:57
	>в /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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "'тоже мне проблемы' (ц)"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 20:10
	>Во FreeBSD: в /usr - базовая система, /usr/local - софт собственно FreeBSD >_не_ являющийся ... но это же сложно и нелогично!, это же >надо иметь степень доцента философии как минимум чтобы просто понять! Бедный >Миша ... Вообще-то я слегка в курсе, что куда суют по ФС во фре.  Даже со своей скромной магистерской степенью.  Не стоит так переживать :) >>Как во фре предлагаете различать собранное из портов и руками из тарбола, >>который в портах отсутствует?  В /opt ставить? ;-) >Во FreeBSD предлагается сделать порт (это просто) и устанавливать уже его. >Как впрочем и во всех вменяемых линуксах - только там слово "порт" >заменяют на слово rpm, deb, ebuild, whatever ... Я опять же в курсе, как рекомендуется.  И поддерживаю порядка двухсот пакетов.  При этом не верю, что уважаемый аноним всё всегда ставит из портов/пакетов -- равно как и десять тыщ мильёнов его коллег по цеху. >Впрочем предвижу - ты Мы с Вами разве пили на брудершафт? >затянешь волынку на тему а как без этого Не-а, потому что прекрасно знаю, как.  Вот только практика показывает, что знают-то не все, не то что следуют таким рекомендациям. Собсно новость тому ярким подтверждением. >... ну ответ всегда один - раз делаешь руками - вся >ответственность на тебе! Именно ;-) >>...для очень нужной задачи "получить никому не нужную голую систему". >Да - задача сомнительная :) Но задача "отказаться от FSH чтобы можно >было иметь 2 версии одного софта" - вообще что то феерическое >:) О чём, собственно, и речь :-) (btw "FHS")
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	88. "'тоже мне проблемы' (ц)"
	Сообщение от Аноним (??) on 19-Авг-08, 20:56
	>>:) >О чём, собственно, и речь :-) (btw "FHS") Очепятки happen :) Миша - не обижайсо, на "ты" я не со злобы! Но будь реалистом - это общепринято. Главное же в нашем разговоре не это. Вот смотрите: он - Линуксоид, я - больше Фряшник. А по всем главным моментам у нас подозрительно схожие мнения. Думаю это потому что есть инженерный подход (да-да - седая классика, анализ\синтез) и он приводит к FHS и пакетным менеджерам. А есть буйная анархия\фантазия\право делать глупости ... которая тоже нужна - ибо без этого новых идей и не будет. Только новые идеи все равно попадают на зубок к инженерам ... которые их либо принимают и воплощают в реальность ... либо подумав над "этим Goblinux-ом" откладывают. В данном конкретном случае решение приносит больше проблем, чем пользы ==>  "в сад!" Вот такое HO. GR.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	97. "'тоже мне проблемы' (ц)"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 23:09
	>Миша - не обижайсо, на "ты" я не со злобы! Но будь >реалистом - это общепринято. Помнится, у фидошников -- но не в моём обычном кругу общения. >Главное же в нашем разговоре не это. Так отож ;-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	107. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от oops on 20-Авг-08, 05:59
	>>на самом деле проблема есть. в линухе с организацией файлов бардак.(хотя думаю >>от дистриба зависит). >>во фре, например, софт ставиться в /usr/local/ >Вы бы всё-таки перестали попугаить эту ерунду.  "В линуксе" с организацией >файлов бардака как раз на порядок меньше, чем во фре: ну-ну.. >в /usr/local собранное _локальным_ администратором, в /usr -- установленное системно при помощи >средств управления ПО. Ничего не понял. pkg_add, make install, portupgrade считаются системными средствами управления ПО? >Как во фре предлагаете различать собранное из портов и руками из тарбола, >который в портах отсутствует?  В /opt ставить? ;-) Нормально прописывать префикс при configure. 70% патчей в портах этим и занимается. Можно и в порт завернуть. >> что бы удалить весь софт и получить девстенную систему нужно сделать rm -rf /usr/local >> все просто и логично. >...для очень нужной задачи "получить никому не нужную голую систему". где в начальном посте говорилось о "очень нужной задаче"?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	116. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 20-Авг-08, 11:34
	>>в /usr/local собранное _локальным_ администратором, в /usr -- установленное системно >>при помощи средств управления ПО. >Ничего не понял. Человеку на пальцах объяснил семантику /usr{,/local} _в линуксе_.  Наверное, стоило ещё добавить, что нет разделения на "базовую систему" и "софт второго класса" -- всё, установленное из пакетов дистрибутива, относится к дистрибутиву.  Подход другой. >pkg_add, make install, portupgrade считаются системными средствами управления ПО? Первое и последнее -- да, второе -- смотря где делать.  Подразумевалось же в /usr/ports? :) >>Как во фре предлагаете различать собранное из портов и руками из тарбола, >>который в портах отсутствует?  В /opt ставить? ;-) >Нормально прописывать префикс при configure. 70% патчей в портах этим и занимается. >Можно и в порт завернуть. Эт понятно, но предложение подумать было не к Вам :) (хотя...)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	123. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от oops on 20-Авг-08, 12:43
	>>>в /usr/local собранное _локальным_ администратором, в /usr -- установленное системно >>>при помощи средств управления ПО. >>Ничего не понял. >Человеку на пальцах объяснил семантику /usr{,/local} _в линуксе_.  Наверное, стоило ещё >добавить, что нет разделения на "базовую систему" и "софт второго класса" >-- всё, установленное из пакетов дистрибутива, относится к дистрибутиву.  Подход >другой. >>pkg_add, make install, portupgrade считаются системными средствами управления ПО? >Первое и последнее -- да, второе -- смотря где делать.  Подразумевалось >же в /usr/ports? :) уже потом увидел, что тут речь про линуксовый FHS.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	129. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от iZEN (ok) on 20-Авг-08, 17:54
	>Вы бы всё-таки перестали попугаить эту ерунду.  "В линуксе" с организацией >файлов бардака как раз на порядок меньше, чем во фре: в >/usr/local собранное _локальным_ администратором, в /usr -- установленное системно при помощи >средств управления ПО. В каталог /usr ставятся приложения во время пересборки мира. При помощи средств управления ПО (утилиты pkg_*) формируются подкаталоги каталога /usr/local. >Как во фре предлагаете различать собранное из портов и руками из тарбола, >который в портах отсутствует?  В /opt ставить? ;-) Написать свой порт. Это относительно несложно, зато он будет подчиняться правилам установки/удаления программ во FreeBSD и не замусорит систему.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	132. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от andr.mobi (??) on 20-Авг-08, 18:46
	> Как во фре предлагаете различать собранное из портов и руками из тарбола, > который в портах отсутствует? Собрать надо порт, и все дела. Гемора гораздо меньше, чем руками, и удовольствия больше, особенно если левой.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	135. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 20-Авг-08, 18:57
	>> Как во фре предлагаете различать собранное из портов и руками из тарбола, >> который в портах отсутствует? >Собрать надо порт, и все дела. Повторюсь: я в курсе, как "надо".  Все ли в курсе (и следуют ему) из использующих?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	137. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от oops on 21-Авг-08, 08:04
	>>> Как во фре предлагаете различать собранное из портов и руками из тарбола, >>> который в портах отсутствует? >>Собрать надо порт, и все дела. > >Повторюсь: я в курсе, как "надо".  Все ли в курсе (и >следуют ему) из использующих? Все ли собирают честный пакет на RPM когда нет готового?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	138. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 21-Авг-08, 08:11
	>Все ли собирают честный пакет на RPM когда нет готового? Если это несколько скриптов с парой конфигов или веб-интерфейс, то пакет не собираю. Если это программа с make-файлом, то пытаюсь использовать хотя бы checkinstall для сборки deb-пакетов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	139. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от pavel_simple (??) on 21-Авг-08, 10:01
	>>Все ли собирают честный пакет на RPM когда нет готового? > >Если это несколько скриптов с парой конфигов или веб-интерфейс, то пакет не >собираю. >Если это программа с make-файлом, то пытаюсь использовать хотя бы checkinstall для >сборки deb-пакетов. dh-make?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	140. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 21-Авг-08, 10:09
	>dh-make? Каюсь, грешен, до сих пор ещё не удосужился изучить инструменты разработчика debian. Хотя уже скачал и распечатал руководство на русском.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	152. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 21-Авг-08, 15:43
	>>>> Как во фре предлагаете различать собранное из портов и руками из тарбола, >>>> который в портах отсутствует? >>>Собрать надо порт, и все дела. >>Повторюсь: я в курсе, как "надо".  Все ли в курсе (и >>следуют ему) из использующих? >Все ли собирают честный пакет на RPM когда нет готового? Воот.  Не все.  Но для лодырей и есть /usr/local.  Я ж к чему подводил? ;-) PS: сам несколько лет тому устрожил на localhost принцип "почти никогда не ставить самосбор в /usr/local" до "или оно запускается из ~/src, или собирается в пакет и устанавливается" после довольно неочевидной отладки чего-то падавшего, пока не догадался ldd на бинарник дёрнуть...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Larin (??) on 19-Авг-08, 11:55

*девственную

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от NarkTranquility on 19-Авг-08, 12:13
	а как же база данных установленных пакетов? ее же тоже надо удалить для "девственнизации" системы :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Я (??) on 19-Авг-08, 12:30
	>а как же база данных установленных пакетов? ее же тоже надо удалить >для "девственнизации" системы :-) А ее - при желании - тоже можно хранить в /usr/local :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Larin (??) on 19-Авг-08, 12:34
	>а как же база данных установленных пакетов? ее же тоже надо удалить >для "девственнизации" системы :-) ладно. уговорил, нужно ввести два раза rm :))) но в любом случае логичность должна присутствовать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от oops on 19-Авг-08, 14:12
	>>а как же база данных установленных пакетов? ее же тоже надо удалить >>для "девственнизации" системы :-) > >ладно. уговорил, нужно ввести два раза rm :))) >но в любом случае логичность должна присутствовать. pkg_delete -f \* и максимум что останется - конфиги в etc. в линукс, да.. логичности бы не помешало.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от port on 19-Авг-08, 12:11

Читаю я коменты выше и недоумеваю - товариСчи, а вы хотя бы разобрались в вопросе или просто только бы чего умного ляпнуть? Если знаете английский то почитайте дружественный фак для начала, а потом ответы на большинство изложеных в комментах выше клише. http://gobolinux.org/index.php?page=faq http://gobolinux.org/index.php?page=doc/articles/clueless

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 15:41
	>Читаю я коменты выше и недоумеваю - товариСчи, а вы хотя бы >разобрались в вопросе или просто только бы чего умного ляпнуть? Они же сами в оном факе пишут -- "мы идиоты и не нужны": 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/
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Аноним (??) on 19-Авг-08, 17:40
	Хотя ты Миша и простреленный в голову, но с этим твоим постом согласен полностью! FHS - в Линуксе это то за что надо держаться обеими руками и биться за него до смерти! Если и это похерят - Линуксу конец ... правда я не верю что нормальные люди на это пойдут :) Кстати всё сказанное не означает что FHS должен быть неизменным - всё меняется и он должен меняться. Эволюционно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от avatar (??) on 19-Авг-08, 12:30

Интересно, а я бы попробовал.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

33. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от azz on 19-Авг-08, 12:35

Забавно посмотреть на вывод ldconfig c /Programs/OpenOffice/1.1.4 и, /Programs/OpenOffice/2.0

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

35. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 19-Авг-08, 12:50

ппц. принципы организации иерархии директорий это уже потаенное знание, требующее обсуждений, публикаций с толкованиями и альтернативные решения. потерялись знания предков, пока весело тащили линух на десктоп. от ГомоЛинух просто плакать хочется и умолять "госпади не приведи мне юзать ЭТО на производстве".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

40. "OpenNews: Проблемы организации иерархии файловой системы в L..."

Сообщение от Crazy Alex on 19-Авг-08, 13:25

Гм... Совершенно невнятная идея. Такое впечатление, что люди придумали проблему, а потом ее решают. Если им так важно, чтобы можно было легко удалять программу, поставленную не из репозитория - checkinstall и аналоги в помощь. Не говоря о make uninstall... А если уж софт uninstall не поддерживает - ровно также он может записать любые файлы куда попало. Товарищ прицепился к паре рудиментов вроде /use/X11R6, а на остальное просто фантазия богатая. Ну лежит часть бинарников в /sbin, часть в /bin - дык и разделение там есть - на нужные руту и общие, и не особо принципиально это, вообще говоря... Их уродливые названия каталогов программ - это вообще нечто. Не знаю, кто как - но лично я это запоминать и набирать из командной строки не стремлюсь совершенно. Зато трехбуквенные стандартные названия, понимаете ли, устарели... Конечно, может, "домохозяйкам" это и удобно, но эффективной работе с системой точно не способствует. Симлинки - это вообще бред какой-то. просто rm -R /Programs/SomeProg не пройдет - нужно еще поубивать все симлинки на удаленные файлы, то есть нужен-таки какой-то инструмент - дык и пусть он полностью удаляет софтину, чего ж проще? Тем более, что режим "удалить, но оставить конфиг" тоже никто не отменял, и реализовывать его как-то надо. Ну, там еще масса возражений может быть, но основное - люди пытаются решать несуществующие проблемы.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от аноним on 19-Авг-08, 13:43
	Для десктопа, не видел ничего удобнее системы установки/удаления программ, чем в мак ос. Было бы здорово, если бы такое сделали и для линукса, без гиморных зависимостей и прочих make uninstall, которые обычному пользователю не нужны, да и вряд ли он об этом знает. И знать ему не нужно. Просто и по-человечески, перетащил программу мышкой куда тебе захочется и используешь. На серверах это все ни к чему, согласен.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от www2 (??) on 19-Авг-08, 13:54
	>Просто и по-человечески, перетащил программу мышкой куда тебе захочется и используешь. По-человечески - это как есть сейчас, через пакетный менеджер. А "перетаскивать мышкой программы куда захочется" - верный путь к бардаку и вирусам, и большой шаг назад в деле достижения модульности, отслеживания зависимостей и актуальности библиотек и программ.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	121. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от аноним on 20-Авг-08, 12:20
	>>Просто и по-человечески, перетащил программу мышкой куда тебе захочется и используешь. > >По-человечески - это как есть сейчас, через пакетный менеджер. А "перетаскивать мышкой >программы куда захочется" - верный путь к бардаку и вирусам, и >большой шаг назад в деле достижения модульности, отслеживания зависимостей и актуальности >библиотек и программ. Вы пробовали или предполагаете?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	122. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от www2 (??) on 20-Авг-08, 12:29
	>Вы пробовали или предполагаете? Я - пробовал. А вы?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	128. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от аноним on 20-Авг-08, 17:14
	>>Вы пробовали или предполагаете? > >Я - пробовал. А вы? Дома у меня мак ос, на работе линукс. И ей богу, не понимаю, почему мне для установки например пиджина, необходимо доустановить еще кучу пакетов. А для установки Адиума (версия пиджин на маке), использующего ту же библиотеку что и пиджин, необходимо всего лишь перетащить приложение в Applications. Если мне необходимо удалить приложение, я перетаскиваю его в трэшкэн и мне не надо помнить о куче доустановленных пакетов в виде библиотек. По-моему, тут гораздо больше порядка, чем в линуксе с его депендсами. И более наглядно для пользователя, если мы уж начали говорить о контроле над системой. Естественно это интересно для десктопа.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	130. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от www2 (??) on 20-Авг-08, 17:55
	>Дома у меня мак ос, на работе линукс. И ей богу, не >понимаю, почему мне для установки например пиджина, необходимо доустановить еще кучу >пакетов. Ну например потому что пиджин эти пакеты использует. Кроме того, кто ВАС заставляет что-то доустанавливать? Этим должна заниматься система пакетного менеджмента. >А для установки Адиума (версия пиджин на маке), использующего ту >же библиотеку что и пиджин, необходимо всего лишь перетащить приложение в >Applications. Устанавливаете таким же образом ещё одну программу, использующую ту-же библиотеку - и у Вас уже две копии одной и той же библиотеки. А в случае ошибки или уязвимости в библиотеке нужно будет обновлять обе. А иначе, предположим, - угонят аккаунт или при определённых обстоятельствах программа будет вылетать, что тоже не очень приятно. >Если мне необходимо удалить приложение, я перетаскиваю его в трэшкэн >и мне не надо помнить о куче доустановленных пакетов в виде >библиотек. А в чём собственно проблема? Я набираю "aptitude remove пакет" и пакет удаляется со всеми пакетами, которые ему нужны были для работы, но больше не нужны другим пакетам. Если не нравится консоль, можно найти графическую оболочку (Synaptic вроде есть). >По-моему, тут гораздо больше порядка, чем в линуксе с его >депендсами. Вы не правы. Почему - уже объяснил в примере про две библиотеки. Плюс к этому могу привести ещё аргументы: 1. Пользователь поставил куда-то программу, а теперь хочет её удалить, но не может вспомнить, куда он её поставил. 2. Программа для пиджина хочет установить новый скин или смайлы, но не может его найти, т.к. не знает, куда её поставил пользователь. А пользователь, опять таки, сам забыл, куда он её поставил. 3. Злой хакер Вася Пупкин дал пользователю протрояненую программу. Пользователь этого просто не заметил. 4. Одна из программ прописала модуль-сервер в автозагрузку, а пользователь перенёс программу в другое место, и теперь этот модуль не запускается при загрузке и программа не работает. >И более наглядно для пользователя, если мы уж начали говорить >о контроле над системой. Более наглядно - открыть графический пакетный менеджер, по описанию найти нужную программу, выбрать её и нажать кнопку "установить". Или запустить пакетный менеджер и нажать кнопку "обновить систему". Или запустить пакетный менеджер, посмотреть список установленных программ, найти ненужную, отметить её и удалить. Более наглядно для пользователя вообще работать с документами, и не вдаваться в то, что такое "файловая система". Многие макосники, кстати, я слышал, даже не знают что это такое! Уж не знаю анекдот ли это или нет... >Естественно это интересно для десктопа. Как я уже объяснил - не интереснее. И кроме того, чем десктоп принципиально отличается от сервера? И там и там есть операционная система и есть программы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	131. "(offtopic) маковые 'пакеты'"
	Сообщение от Michael Shigorin (ok) on 20-Авг-08, 18:01
	>не понимаю, почему мне для установки например пиджина, необходимо доустановить еще кучу >пакетов. Потому что он не таскает этот код с собой. >А для установки Адиума (версия пиджин на маке), использующего ту >же библиотеку что и пиджин, необходимо всего лишь перетащить приложение в >Applications. Библиотека откуда берётся?  А знание, куда надо перетащить -- проще апта или сложнее? >Если мне необходимо удалить приложение, я перетаскиваю его в трэшкэн >и мне не надо помнить о куче доустановленных пакетов в виде >библиотек. aptitude помнит, что пакет потащил, и при его сносе старается снести и лишнее (если оно никому ещё за прошедшее время не потребовалось). >По-моему, тут гораздо больше порядка, чем в линуксе с его депендсами. Только по-Вашему.  В средневековье без электричества тоже было куда проще... >И более наглядно для пользователя, если мы уж начали говорить >о контроле над системой. Естественно это интересно для десктопа. Да, /ощущение/ контроля над системой софтом в .dmg, безусловно, приятнее. Джобс и вообще такой же торговец ощущениями, как и Гейтс, только более талантливый. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	155. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от fi (ok) on 22-Авг-08, 00:44
	>Дома у меня мак ос, на работе линукс. И ей богу, не >понимаю, почему мне для установки например пиджина, необходимо доустановить еще кучу >пакетов. А для установки Адиума (версия пиджин на маке), использующего ту >же библиотеку что и пиджин, необходимо всего лишь перетащить приложение в >Applications. Ой не надо про mox !!! Вот где бардак!!! Даже винда выглядит приличнее!!! по верх старой доморощенной бсд накручены старые маковские каталоги, без всякой логики. КОШМАР!! Живите по POSIX - и будет Вам счастье!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "OpenNews: Проблемы организации иерархии файловой системы в L..."
	Сообщение от exah on 19-Авг-08, 14:36
	Попробуй slax http://www.slax.org
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

45. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 19-Авг-08, 14:04

Авторы гоболинукса придумали сами себе проблему и теперь ее решают. Переименование рута в зеро придает этому дистрибутиву некую завершенность, как в старом анекдоте про расстрел жидов и велосипедистов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

48. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от exn (??) on 19-Авг-08, 14:57

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

50. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 19-Авг-08, 15:16

Есть проблеммы, или так или иначе возникнут в будущем! Запутанная она, не интуитивно понятная. Не читал скажите не разбирался, нет разобрался, но считаю не прозрачной не понятной. Считаю современные пакетные менеджеры перегруженными, особенно rpm. Нужно сделать так чтобы была возможность обходится без него (пакетного менеджера). gobolinux со своими ссылками это конечно страшно, еще более запутывает, и не эффективно. Но идея gobolinux, а также pc-bsd - будущее. При чем тут попахивает виндой или маком?... надо брать лучшее из всех OS. И не стоит фанатеть и следовать тупо заветам предкам (это касается иерархии файловой системы в Linux). В BSD правильно говорят, многое продуманее сделано, но linux прогрессирует сильнее, ускоряется. Мне например, и думаю большинству не жалко процессорного времени, и памяти (поскольку сегодня она дешевая), и места на НЖМД. проще посмотреть в папку с программами (неважно как будет папка называтся) и видеть что стоит допустим апач 2.1... и апач 2.2 и удалить старую версию, хотя для ленивых это может сделать пакетный менеджер. Хотя тут есть пару камней, но думаю это можно решить. 1. Допустим программы используют одинаковые порты... 2. Программы используют одинаковые библиотеки... В общем надо новый стандарт иерархии файловой системы в Linux, Двигатся надо в сторону х64 битных систем... главное всё под GPL!!! А может кому то лень? стал стар? кого то всё уже устраивает?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 19-Авг-08, 15:48
	>Хотя тут есть пару камней, но думаю это можно решить. >1. Допустим программы используют одинаковые порты... >2. Программы используют одинаковые библиотеки... Это камни, возникающие на ровном месте из-за стремления "чтоб не как у других". Современные пакетные менеджеры решают эти задачи. >В общем надо новый стандарт иерархии файловой системы в Linux, Двигатся надо >в сторону х64 битных систем... главное всё под GPL!!! Да-да, и чтобы Вам на блюдечке всё это поднесли и уговаривали: "Ну пользуйся, ну посмотри какая удобная система! Ведь всё для тебя старались делали! И совершенно бесплатно!" >А может кому то лень? стал стар? кого то всё уже устраивает? Похоже, что кому-то лень изучить пакетный менеджер, этот кто-то слишком молод чтобы найти плюсы при таком большом количестве минусов, и его не устраивает работающее решение.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Аноним (??) on 19-Авг-08, 15:54
	>Считаю современные пакетные менеджеры перегруженными, особенно rpm В slackware или arch простые и понятные каждому менеджеры пакетов. >И не стоит фанатеть и следовать тупо заветам предкам Вот именно, вы наверное помните дос. То что относилось к операционке лежало в c:\dos, а закрытые программы устанавливались туда куда сами хотели. Не ужели вы думаете, что создатели unixa были такими тупыми, что решили всё разделить? Это новая категория мышления - человек, отличаетя от обезьяны тем, что пытается всё раскладывать по полочкам (причём его не сильно беспокоит, что иногда предмету не удаётся подобрать полочку или наоборот, что его можно положить сразу на несколько). >В общем надо новый стандарт иерархии файловой системы в Linux. А может кому то лень? стал >стар? кого то всё уже устраивает? В америке словом pine называют ёлку, кедр, сосну и все остальные хвойные деревья. Они пытаются сделать биологию user-friendly. Тем же самым какие-то люди занимаются в отношении linux. Уверен, что эти меры не пройдут (в качестве стандарта), поскольку здравый смысл рано или поздно одержит верх над тупизной.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

51. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 19-Авг-08, 15:27

В очередной раз понимаю, что всё уже придумано до нас и VMS рулит. Там нету никаких позорных PATH-ов, а есть системные и пользовательские таблицы команд и библиотек ;) Так что раскладывать программы можно как угодно, хоть вдоль, хоть поперёк, а хоть бы и вовсе крестиком - главное в нужной таблице всё зарегистрировать

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Онанимус on 19-Авг-08, 16:51
	Опередил меня предыдущий Аноним... Хотел сказать, что, может быть, дело не в несовершенстве той или иной иерархии файлов в системе, а в том, что несовершенна сама идея иерархической организации? Когда-то изобретение древовидной файловой системы было прорывом, но, может быть, пора подумать об об организации файлов (в том числе -- программ и библиотек) в виде базы данных?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	65. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 17:05
	>но, может быть, пора подумать об об организации файлов (в том числе -- >программ и библиотек) в виде базы данных? Ну подумайте :) PS: "и хде теперь ваша VMS?" ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	124. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от belkin (ok) on 20-Авг-08, 12:45
	>>но, может быть, пора подумать об об организации файлов (в том числе -- >>программ и библиотек) в виде базы данных? > >Ну подумайте :) > >PS: "и хде теперь ваша VMS?" ;) На своём прежнем месте надёжных промышленных систем. http://h71000.www7.hp.com/servermatrix.html HP пыталась после слияния с Compaq её похоронить, но влиятельные заказчики стукнули им по башке и HP её перенесла на Itanium.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	125. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 20-Авг-08, 13:13
	>HP пыталась после слияния с Compaq её похоронить, но влиятельные заказчики стукнули >им по башке и HP её перенесла на Itanium. hint: читается "Итаник"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	156. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от fi (ok) on 22-Авг-08, 00:50
	>HP её перенесла на Itanium. Ага, и теперь хоронят вместе с ним :DDDD Уже почти все модели с ним умерли - упокой их душу....
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

61. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 19-Авг-08, 16:37

Проблема действительно существует? Неявность распредение программ по bin и sbin мне кажется не очень веский аргумент для переделывания структуры ФС. Про резервирование всех файлов программы уже писали (какая-то странная необходимость). Конфиги бэкапяться легко. Для домохозяек скрыть "ужос" структуры ФС можно на уровне менеджера файлов DE, с помощью виртуальной файловой системы, которая представит все каталоги в удобном и понятном виде, сгруппирует файлы/библиотеки, даст читаемые названия и т.п.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

70. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от i (??) on 19-Авг-08, 18:16

насчет opt не согласен, изаю его для прог со своим инсталлером (платный софт как правило)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

72. "прогресс"

Сообщение от fix (??) on 19-Авг-08, 18:54

Радетелям пакетных менеджеров задаю вопрос: вам не кажется, что пресловутые менеджеры в большинстве случаев не полностью выполняют своё предназначение? Как они разруливают вопрос с организацией параллельной установки разных версий программ, если это не заложено при сборке пакета? Могут ли они восстановить или проверить целостность инсталляции? Слишком много полномочий передаётся мэнтейнеру. Пользователю остаётся лишь уповать на то, что мэнтэйнер "правильный" и не завалит систему, переписав половину /bin своими файлами.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "ещё как :)"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 19:21
	>Радетелям пакетных менеджеров задаю вопрос: вам не кажется, что пресловутые менеджеры в >большинстве случаев не полностью выполняют своё предназначение? Не-а.  В подавляющем большинстве случаев они прекрасно справляются :) >Как они разруливают вопрос с организацией параллельной установки разных версий программ, >если это не заложено при сборке пакета? Если есть файловые конфликты (например, обе версии содержат usr/bin/softinka) -- то разве что ставить в разные корни (в rpm возможность relocation теоретически есть, практически пользоваться не доводилось -- и, кажется, должна быть разрешена, т.е. "заложена при сборке пакета"). >Могут ли они восстановить или проверить целостность инсталляции? rpm -- издревле; с dpkg до недавних пор было сложнее (суммы не считались), но вроде и там дорабатывали. >Слишком много полномочий передаётся мэнтейнеру. Ему передаётся необходимое и достаточное количество полномочий: обладание компетенцией по сборке данной программы для данного дистрибутива. >Пользователю остаётся лишь уповать на то, что мэнтэйнер "правильный" >и не завалит систему, переписав половину /bin своими файлами. Во-первых, пользователю всегда приходится более или менее доверять другим: полный аудит *всего* кода, который исполняется на заданной системе -- как минимум нетривиальное занятие. Во-вторых, у пользователя всегда есть выбор: - кому доверять - кому _не_ доверять - сделать лучше самому и предложить вместо Причём эти "первые" и "вторые" _принципиально_ не зависят от ОС, хотя сложность выбора и трудоёмкость реализации, конечно, зависит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

75. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 19-Авг-08, 19:22

Ээээ.... нахрена мне опен офис 1.4 если есть 2.0? :-) Почему в моей убунте нет такой проблемы, как у этих парней? Задолбали уже со своим анальным рабством...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

78. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Света on 19-Авг-08, 19:55

Недостаток запихивания почти всех бинарников в /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, система будет загружаться и при отсутствии данных каталогов).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 19-Авг-08, 20:00
	>Недостаток запихивания почти всех бинарников в /usr/bin, библиотек в /usr/lib - комп немного притормажывает, если зайти в них. Сканирование /usr/bin/ -- нечастая операция.  Для программ практически вообще ненужная. [skip] > procfs:/ Мгм.  И konqueror определить ядерным тредом? :]
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Сканирование on 19-Авг-08, 20:16
	> Сканирование /usr/bin/ -- нечастая операция.  Для программ практически вообще ненужная А пользователя немного напрягает. В общем, одна из множества мелочей, которые ни на что не влияют, но от которых хотелось бы избавиться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от eee (ok) on 19-Авг-08, 20:35
	А как быть с x32 и x64 бинарниками? У меня есть */lib и */lib64, x32 бинарники в /usr/bin/32
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 19-Авг-08, 20:38
	>А как быть с x32 и x64 бинарниками? > >У меня есть */lib и */lib64, >x32 бинарники в /usr/bin/32 Вас это беспокоит? Вы хотите об этом поговорить? :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	87. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от eee (ok) on 19-Авг-08, 20:43
	Понятно что дела похо :(
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Аноним (??) on 19-Авг-08, 21:03
	>Понятно что дела похо :( Ну а как тут без костыля? Правда 32 софта на 64 системах с каждым годом всё меньше ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	149. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от SKeeper on 21-Авг-08, 12:15
	>> Сканирование /usr/bin/ -- нечастая операция.  Для программ практически вообще ненужная > >А пользователя немного напрягает. В общем, одна из множества мелочей, которые ни >на что не влияют, но от которых хотелось бы избавиться. Нафиг пользователю вообще в этот каталог заходить??? Чтобы кликнуть мышкой по бинарнику программки? Ну дык все нужное пользователю лежит в менюхах KDE, Gnome etc.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	102. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от eve on 20-Авг-08, 00:25
	Что забыл пользователь в /usr/bin и, уж тем более, в /usr/lib? У него всё на рабочем столе в менюшках.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

91. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Шипицин Илья on 19-Авг-08, 21:14

учите матчасть, зачем два раза rm rm -r /var/db/pkg /usr/local

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

108. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от nanodaemon on 20-Авг-08, 06:20

согласен. в линуксах неразбираемая свалка. собственно это из-за зоопарка линуксов вокруг и отстуствие системной целостности. хороший пример FreeBSD: /usr и /etc для base, /usr/local и /usr/local/etc для стороннего софта из пакеджей и/или портов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	109. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от www2 (??) on 20-Авг-08, 06:39
	>согласен. в линуксах неразбираемая свалка. собственно это из-за зоопарка линуксов вокруг и >отстуствие системной целостности. > >хороший пример FreeBSD: /usr и /etc для base, /usr/local и /usr/local/etc для >стороннего софта из пакеджей и/или портов. Уфф, ничего против фряшников не имею, но они настолько ограничены рамками своей системы... Ну сколько раз вам нужно повторять, что Linux не делится на base и пакаджи/порты? В большинстве Linux даже ядро является пакетом, поэтому такое деление не имеет смысла!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	112. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от GateKeeper (??) on 20-Авг-08, 09:25
	Помнится при установке Слаки некоторые пакеты помечались как required. И такие пакеты есть в любом дистре: kernel - это как минимум, можно еще предложить init в любой его инкарнации, если говорить о дистре, а не о LFS, где под init можем хоть /sbin/reboot предложить. Собственно это и есть с точки зрения фряхи /, /usr, /etc и т.д. Остальное (опять-таки при фряшном подходе) - /usr/local, /usr/local/etc и т.д. Но в общем и целом - каждому видней. И несовместимость разнообразных "ИМХО" не есть повод делить человечество на "дебилов" и "гуру", тем более принадлежность к данным категориям будет меняться на противоположную в каждом из "лагерей сторонников".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	118. "Проблемы организации каши в голове"
	Сообщение от Michael Shigorin (ok) on 20-Авг-08, 11:45
	>Но в общем и целом - каждому видней. Да. >И несовместимость разнообразных "ИМХО" не есть повод делить человечество на "дебилов" >и "гуру", тем более принадлежность к данным категориям будет меняться на противоположную >в каждом из "лагерей сторонников". Э, нет.  Здесь помедленней. Если человек врёт себе и другим, то он никак не "гура".  Хотя может, и не "дебил", а просто  соображать ещё не научился.  Даже если со стажем в NN лет, как вот Андрей Вингородов. А мнения и подходы действительно бывают разные, со своими плюсами и минусами в разных обстоятельствах.  И ошибаемся мы все тоже каждый со своей частотой, но поскольку люди... то неизбежно. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	117. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от Michael Shigorin (ok) on 20-Авг-08, 11:40
	>>согласен. в линуксах неразбираемая свалка. собственно это из-за зоопарка линуксов вокруг и >>отстуствие системной целостности. >>хороший пример FreeBSD: /usr и /etc для base, /usr/local и /usr/local/etc для >>стороннего софта из пакеджей и/или портов. >Уфф, ничего против фряшников не имею, но они настолько ограничены рамками своей >системы... А я против таких имею -- бо зело любят вещать ерунду вроде "в линуксах неразбираемая свалка" и далее по тексту, которую от такого же умника услышал, с ушей не снял (вилки нет, шапку с четырьмя козырьками тоже ещё не заработал) -- и радостно дальше транслировать без попытки обдумать и тем более проверить. Какая нафиг "системная целостность" при отсутствии ресурсов на бранчи портов? :( >Ну сколько раз вам нужно повторять, что Linux не делится на base >и пакаджи/порты? В большинстве Linux даже ядро является пакетом, поэтому такое >деление не имеет смысла! При этом выделить компактную базовую систему в приличных случаях вполне возможно.  Только содержать она будет не компилятор, а менеджер пакетов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

114. "Проблемы организации иерархии файловой системы в Linux"

Сообщение от Аноним (??) on 20-Авг-08, 11:14

При всем этом они забыли, что юникс это изначально многопользовательская система. и каждый юзер имел домашний каталог. И если ставилась более-менее нужная всем программа- она ставилась в /usr/local. А если конкретного васю пупкина не устраивал офис-1, то ему ставился офис-2 в /home/vpupkin/[opt..bin..etc..] - эту иерархию никто не отменял и все разруливалось короткими путями. А еще во вменяемой программе должен быть вариант make uninstall. Ну или при работе менеджеров пакетов это уже проблема дистростроителя. Программы ставить и сносить сотнями в день - это вариант знакомства с системой, при нормальной ежедневной осознанной работе это уже не надо.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	134. "Проблемы организации иерархии файловой системы в Linux"
	Сообщение от andr.mobi (??) on 20-Авг-08, 18:55
	>При всем этом они забыли, что юникс это изначально многопользовательская система. И ещё все не хотят вспоминать, что создатели UNIX ещё долго после 70-го, и после 92-го,  развивали свою ОС, и решения для Plan9 в очень многих местах радикально отличны от первоначальных решений в UNIX, в том числе и для иерархии каталогов, линков на файлы и способов монтирования. Найдены гораздо более простые и практичные решения, чем те, которые юзают и заново изобретают линуксологи. А уж на маздайных ламеров смотреть тошно, как они прямо болеют без диска C:\\, их хлебом не корми, только дай завести какое-нибудь чудо вроде "Программные Файлы" или запихать три строчки из /etc/fstab в OpenXML(tm)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]