К Гобо есть две (умозрительных) претензии:
1) В идеале, лучше бы не ВСЕ пакеты так ставить, а только те,
что хочется, и не в /Programs/Systems/Utils/Blahblahblah/
а под одну mount-point типа /opt.
2) Пути называются слишком длинно и неэкономно - во-первых,
трудно читать, во-вторых - запоминать ( а где ж это лежало -
в /System/scripts/util/sysinfo/1.2/bin или в
/Programs/sysinfo/1.4/scripts/bin?) Ну, а в тертьих, без
автокомплита в шелле такие имена за####ся печатать.

Но, в принципе, идея здравая, хотя и не очень новая -
MacOS X тоже не слишком рьяно следует обычному FS layout,
но хуже от этого не становится ж)

2ov:
Дааа.....
Я неоднократно видекл как народ выносит программы
с помощью удаления d:\quake2, d:\quake3 и через 3 месяца
в меню "пуск" лучше не заходить, плюс половина програм не устанавливается
потому что в registry уже есть о них запись.
Например rm -rf /usr/soft/qt/ не удалит запись designer в /etc/menu/windowmaker
(в отличие от apt-get remove qt) да и не только это...
И что делать с /usr/lib/pkgconfig/*?
А логи тоже хранить не в /var/log а в /usr/soft/apache ?
А что будет при переполнении диска /usr/soft логами апача ?
(на нормальных серверах /var - это другой раздел, ровно как и /home)
Короче как всегда - идея не такая уж плохая - но (из-за того что не
разобрались) нормальное исполнение просто невозможно.

Вообще Unix это просто _другая_ идеология. И глупо говорить что
он фиговый просто потому что у него нет кнопки "Пуск".
Это примерно то же что и говорить что американцы дураки потому
что не говорят по русски. А со своим уставом в чужой монастырть лучше
не соваться, и уж точно root'a не переименовывать в Administrator'a...
( Я еще бы понял если бы в BillGates'a ;) )

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

я не призываю к смене FSH революционным путем :) но я очень не против ее эволюции во что-то чуть более организованное.

> но я очень не против ее эволюции во что-то чуть более организованное

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

Хм..... Похожая структура каталогов была еще в NeXT, если память не изменяет

А я вот, после более-менее упорядоченных размещений каталогов в BSD-системах, просто ужасаюсь, что твориться с файловым деревом Линукса. Посадите пингвинукса на другой, отличный от его родного дистрибут - он там в поисках нужных конфигов тыкаться будет как слепой котенок пол дня. Просто срачь развели - не дерево каталогов, а просто свалка. Половина конфиги пишет в /etc/* и /usr/local/etc/*, как вроде бы логично. Но часть прог теперь полюбила такие места как /usr/libexec/* /usr/local/libexec/*. Это что - сейчас модно так? Расшврыть конфиги так, чтобы никто кроме тебя там нифига не срубил?

Вот сижу, читаю и в очередной раз поражаюсь стройности и логичности идеологии юникса! Вещи, придуманные пол-века назад замечательно заботают и сейчас, и, вероятно, будут работать еще долго. Сам-то обычно смотря на "ФС через какой-нибудь каммандрер" долго не мог понять, какого черта все раскидано, почему нет на программу каталога, почему все так неудобно искать/удалять. И вто наконец понял... и см. начало.

> почему все так неудобно искать/удалять

А почему в вагоне поезда нет стоп-крана на каждом пассажирском месте? И что такое bonobo?

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

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

один каталог - одна программа это не хаос, больший хаос - все программы в одной куче + я не предлагаю _ВСЁ_ распихивать по разным каталогам, стандартное содержимое каталогов /bin /sbin и многое что ставилось в /usr/bin /usr/sbin естественно лучше оставить (системные програмки типа ls, cp, ps, ifconfig и прочее), а вот зачем мне компилить програму в /usr, тем более если нет make uninstall, а если я захочу удалить её... а обновлять? обновлю из того же пакета (рпм например) какуюнть программу, окажется что старая версия мне подходила больше или поставлю взамен стабильной программы, особо новую, но не стабильную и она не понравится - чё делать? удалять новую, заново ставить старую - геморрой, если можно ограничиться просто удалением новой, а если ещё исходников/пакета старой не осталось?

Гражданин ov наводит красоту-порядок, раскладывает проги по полочкам каталогам... а попробуем теперь поработать.. ой, command not found... добавим в PATH... ядрен батон, PATH уже на экран не влазит.. ладно, сделаем отстойник из симлинков (да пометим себе в голове что если прогу обновим или снесем не забыть руками симлинк прибить).. ну вот, прогу видно, запускаем - упс, shared library not found... матюкаемся, прописываем папку в ld.so.conf.. та же байда, файлец уже на километр.. ну можно и тут с симлинками lib/ замутить, не беда.. пустили, ага, прога интересная, но как пользоваться хз... смотрим man.. хер, man-страница не найдена.... ковыряем MANPATH, дрючим симлинки, наслаждаемся работающим man... смотрим, а че эта прога просит ttf-шрифты.. они у меня есть но в другой проге, а в разделяемой папке держать некошерно, непонятно ж потом будет - чьи они.. делаем копию... или симлинками.. пробуем скомпилить свежую тулзу... а ей надо пять либ таких-то и 100 хедеров таких-то.. вот засада, вместо того чтобы ./configure сам все подхватил, приходится цеплять гроздья --with-includes ну или CPPFLAGS=-I... такой же стряпать по всем папкам... задолбало, сделаем include/ какой-нить, свалим туда симлинками хедера, опять же не забудем стереть при случае.. инсталляем... очередной криворукий автор --prefix любит-уважает да втихомолку все равно в /etc лезет граблями... материмся, правим makefiles на тему install, ставим.... suid-ные проги да всякие конфиги расползаются по сотне каталогов, но это ничего, мы их помним и за ними присмотрим если что... админим, смотрим логи, пишем скрипт в котором лежат пути до логов каждого демона, а то в одной папке типа /var/log хер разберешь, где чье... и т.д и т.д... зато РАБОТАЕМ, а не ебем мозги, как эти сопляки со своими apt да rpm!

2anonymous (*) (2003-05-19 14:56:12.919)
Ты перегнул палку аданазначна!
ld.so.conf на километр? Ты бредишь!
Я пользую РХ часть пакетов из рпм часть самосборная. Если нужно поставить из тарболов новую прогу на тестирование не уничтожая старую то 1каталог - 1прога это очень даже хорошо! Т.е тушишь старую запускаешь новую. Не нравиться? Тушишь новую, запускаешь старую. В любом случае ты не будешь ставить такое огромное количество софта руками, а завести отдельные каталоги на ~10 прог особых проблем не вызывает.

2anonymous (*) (2003-05-19 14:56:12.919)
на самом деле не всё так сложно и стражно, ттф шрифты не обязательно куданть прятать, лежать они на своём месте и лежат, никому не мешают, трогать ld.so.conf тоже не нада и симлинков для библиотек делать не нада, можно воспользоваться export LD_LIBRARY_PATH (по-моему так переменная называется) я не думаю что работа с линуксом для большенства людей - это постоянное компиление чегонть, после того как программа скомпилировалась, кидается в её каталог скрипт для её запуска (1 сторока) export LD_LIBRARY_PATH /usr/soft/qqq-1.2.3 && /usr..../qqq и делается для неё линк в /usr/soft например - это занимает времени меньше минуты, причём скрипт этот нада далеко не всегда (яб сказал редко) закидывать к свежескомпиленным прогам... да и работа с программой не обязвает постоянно смотреть маны, если нада посмотреть - F3 на этом мане в mc - прекрасно всё смотрится и при этом не материмся и ничё с мэйкфайлами не делаем + всё у нас прекрасно компилится, т.к. всё инклуды и хидеры лежат на местах, там где должны и действительно работаем и не сношаем мозги :)

Да абсолютно тупая это идея
Есть стандартные директории - которые
любой аднин/юзер знает, найдёт в любом
руководстве.

Вся эта затея нужна только затем - чтобы
сносит/ставить программы без менеджера
пакетов (- и править конфиги ручками)

Типа - чайники с трудом пути находят,
ну не уверен что чайникам это понравиться
- править ручками конфиги/пути.

во вторых есть уже /opt, /usr/local куда это засовывать можно хоть бы и в отдельные директории.
В этом случае администраторы да и некоторые
конфигурационные/(де)инсталляционные утилиты
будут хоть примерно знать, где искать.
Пример : ставлю я жабу в /usr/local/j2sdk1.4.1_02
- несколько нестандартно,
но большинство программ, которым эта java
нужна находят её автоматически.

да ты чувак крут маны в mc смотреть по f3, ты наверное и конфиги в openoffice правишь... остальная аргументация того же уровня..

видно ребята man hier не читали
ps: RPM rulez 4ever

нда

emerge unmerge foo

apt-get remove foo

rpm -e foo

rm -rf /usr/local/foo && rm -rf /etc/foo && rm -rf /var/log/foo && ...

Что более корректно и красиво?

IceD

>Например X-ы стоят там в /Programs/XFree86/4.3/ и т. д.

Эй вы крутые спецы мля. Скажите лучше нахрена мне каждая программа при старте создает директорию ".я тут поставилась мля" - на хер мне это нужно иметь 50 таких каталогов в домашней директории. Только не надо, про то что их скрыть можно. Спрашивается - нахрена ? Что нельзя все в одну директорию .programs все пихать. В $M об этом подумали и еще кучу лет назад организовали Program Files. А знаете зачем - а что бы было удобно. А в вашем мля U* нихрена о ползователях не думают. Таких примеров довига.

Microsoft лицензирует SCO Unix Code

>IceD

Что более корректно и красиво?

rm -rf /usr/local/foo && rm -rf /etc/foo && rm -rf /var/log/foo && ...

find / -name "foo" exec rm {}

кретенизм поражает

>В $M об этом подумали и еще кучу лет назад организовали Program Files.

Угу - в Progra~1 конечно конфиги хранятся. Супер! Для этого великий M$ придумал другую отличную вещь - реестр называется. Только вот обидно - в реестре куча веток \HKCU\Software\Foo\... \HKCU\Software\Bar\... Так ведь ничего и не найдешь. Бардак однозначно. Надо что бы все в корне было!!! FooEntry1, FooEntry2, BarSuperEntry, ... Вот было бы удобно.

кретенизм поражает

>В $M об этом подумали и еще кучу лет назад организовали Program Files.

Угу - в Progra~1 конечно конфиги хранятся. Супер! Для этого великий M$ придумал другую отличную вещь - реестр называется. Только вот обидно - в реестре куча веток \HKCU\Software\Foo\... \HKCU\Software\Bar\... Так ведь ничего и не найдешь. Бардак однозначно. Надо что бы все в корне было!!! FooEntry1, FooEntry2, BarSuperEntry, ... Вот было бы удобно.

IceD

> find / -name "foo" exec rm {}

маладец, держы пирожок.

/* Юзверь с папками foo в $HOME */

for i in `find  / -group foo -type f 2>/dev/null`; do
    rm -i $i   # Сойдет и так, но лучше чтоб тут выскакивало
               # окошко с кнопками "Да", "Нет", "Не уверен"
done


    

> for i in `find / -group foo -type f 2>/dev/null`; do > rm -i $i # Сойдет и так, но лучше чтоб тут выскакивало > # окошко с кнопками "Да", "Нет", "Не уверен" > done

конечно. а у меня на диске например столько файлов/директорий что du -smx /home/* отрабатывает около часа (1533MHz ext3). сколько мне ждать твой find? а не проще ли не изобретать велосипед и воспользоваться packet manager?

>да ты чувак крут маны в mc смотреть по f3, ты наверное и конфиги в openoffice правишь... остальная аргументация того же уровня..

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

------------------------- Эй вы крутые спецы мля. Скажите лучше нахрена мне каждая программа при старте создает директорию ".я тут поставилась мля" - на хер мне это нужно иметь 50 таких каталогов в домашней директории. Только не надо, про то что их скрыть можно. Спрашивается - нахрена ? Что нельзя все в одну директорию .programs все пихать. В $M об этом подумали и еще кучу лет назад организовали Program Files. А знаете зачем - а что бы было удобно. А в вашем мля U* нихрена о ползователях не думают. Таких примеров довига. ------------------------- ну ты просто от души прорулился :)

Microsoft лицензирует SCO Unix Code

>маладец, держы пирожок.

/* Юзверь с папками foo в $HOME */

И это правильно :)

Если в системе есть lynx, то $HOME/lynx подлежит отстрелу.

>for i in `find / -group foo -type f 2>/dev/null`; do

Не я не могу - отдельную группу на каждую прогу. 300 пакетов - 300 групп. Я от смеха сча помру. Каждого юзверя в 200-300 групп запихать. А если юзверей 100?

PS. Запихивать все группы в группу users, а в нее уж юзверей не выход - а вдруг я захочу какому-то юзверю прав куда-то не дать?

IceD

конфиги я правлю в том же mc, но уже через Ф4, а маны в нём смотрятся так же, разве что цветные...

2 IceD

Правильно, так и задумывалось: ведь MaR хочет сохранять контроль над системой - вот пусть и сохраняет, без дела не будет.

2 MaR

Вы хотели пластилина - получите.

Надо пожелание гобовцам засдать - вместо Programs сделать "Program Files" и симлинк Progra~1 на него. А то ни туда ни сюда.

IceD

Microsoft лицензирует SCO Unix Code

конечно. а у меня на диске например столько файлов/директорий что du -smx /home/* отрабатывает около часа (1533MHz ext3). сколько мне ждать твой find? а не проще ли не изобретать велосипед и воспользоваться packet manager?

Ну чего тупите ?

find / -name "foo" \! \(-name "/home" \) -delete

> Ну чего тупите ?

sunch ты подпорками не отмазывайся. выкидываешь /home сам себе противоречишь что /home/lynx must die. ну а если файлуха плотная не в /home а там где проги стоят? твой find это метод гнилой изначально

2Sun-ch:

ты же вроде разумный был

IceD

> конфиги я правлю в том же mc, но уже через Ф4, а маны в нём смотрятся так же, разве что цветные...

Хыхы :)

axe:~$ cat .Xdefaults  | grep Rxvt
Rxvt*loginShell: true
Rxvt*font: -cronyx-fixed-medium-r-*-*-13-*-*-*-*-*-koi8-r
Rxvt*background: black
Rxvt*foreground: white
Rxvt*utmpInhibit: false
Rxvt*scrollBar_floating: true
Rxvt*iconName: unix.xpm
Rxvt*termName: xterm-color
Rxvt*saveLines: 500
Rxvt*colorBD: red                                                               
Rxvt*colorUL: green
axe:~$ 

Смотрим в последние 2 строчки и замечательно имеем цветные MAN'ы :)

Microsoft лицензирует SCO Unix Code

файлуха плотная не в /home а там где проги стоят? твой find это метод гнилой изначально

Если find / работает час, то это очень херовый сервер

Ну а на самом деле, нахрена мне прям в домашней
директории порядка 100 файлов/директорий c конфигами?
Почему б не запихать их всех в отдельный подкаталог?
Я знаю, можно сделать, чтоб они не отображались в моём
любимом "каммандере", но, мать, а если мне надо какой
конфиг подправить? Постоянно включать "показывать/непоказывать
скрытые файлы"?
Вот Zulu умный, пусть объяснит. :)

> Если find / работает час, то это очень херовый сервер

Не виляй. Понятие сервер растяжимое, не надо его сюда вплетать. Просто на машине _много_ файлов (ну по работе надо).

А чем locate не нравиться при поиске?

Microsoft лицензирует SCO Unix Code

Не виляй. Понятие сервер растяжимое, не надо его сюда вплетать. Просто на машине _много_ файлов (ну по работе надо).

А что rpm -e foo быстрее работает ? Или он файлы быстрее

чем find ищет ? А зависимости с ключем -e он проверяет ?

Я конечно не Zulu. Но чем плохо `cd .fl<Tab>`?

IceD

>Смотрим в последние 2 строчки и замечательно имеем цветные MAN'ы :)

ай маладца! :)
вобще-то я приводил различия при использовании mc и man, а не приимущества :)

>Ну а на самом деле, нахрена мне прям в домашней
>директории порядка 100 файлов/директорий c конфигами?

ну сделай себе отдельный хоум для документов всего остального если хочешь... типа /home/user.docs и сделай ему chown... ибо хранить все настройки всех юзеров в одном каталоге не удобно и тупо...

rpm -e еще как проверяет! насильно только с --no-deps он ищет только файло к удаляемому пакету и вообще то это не тоже что find

2 MaR

Пойми, все, что сказано ниже -- это строгое ИМХО.
Пользуюясь UNIX-like системой ты соглашаешься с ее правилами.
Выбор и удобство -- это рулез, я не спорю.
Но в данный момент все заточено таким образом, что твой подход не совсем верен.
И правильно говорили по поводу $PATH, $LD_LIBRARY_PATH, добавлений к ./configure в виде LDFLAGS и CPPFLAGS кучи параметров и еще чего-то.

У меня многие вещи вынесены в отдельные каталоги --
/usr/local/Acrobat/
/usr/local/apache/
/usr/local/moZilla/
/usr/local/qt/
/usr/loca/java/

Но это такие софтины, которые сами по себе самодостаточны и довольно громоздки.

Кому не нравятся apt-get, rpm и другие манагеры -- смотрите в сторону checkinstall, и ваши волосы будут мягкими и пушистыми :)

2MakcuM
у меня примерно так же, но я и не предлагал _ВСЁ_ по разным каталогам распихавать...

/usr/soft/winex-20020228
/usr/soft/xawtv-3.79
/usr/soft/xchat-1.8.8
/usr/soft/licq-1.2.3
/usr/soft/mozilla-1.3
/usr/soft/mplayer-0.90rc5
/usr/soft/xchat-1.9.8
/usr/soft/xmms-1.2.7
и т.д.

единственная прога, которая орёт cannot open shared object file: No such file or directory - wine, но она запускается так:
запускающий скрипт:

export LD_LIBRARY_PATH=/usr/soft/winex-20020228/lib
/usr/soft/winex-20020228/bin/wine --winver=win98 -- $*

и всё прекрасно работает, а все мелочи или которые нужны не мне, а другим прогам, я естественно компилю в дефолтовые каталоги, куда они по дефолту просятся...

Объясню, брат-анонимус.
Идея хранить все настройки не в ${HOME}/.foorc, а в ${HOME}/etc/foorc (дополнительные точки расставить по вкусу) хороша, но ее обсуждение в debian-devel@ привело к решению "у нас нет машины времени, чтоб вернуться назад и все исправить". Увы, так исторически сложилось.

Вот, а теперь к вопросу, как я их правлю:
$vim ~/.foorc

Мля, mplayer это такая глобальная и мощная прога с тучей файлов - один бинарник, пара либ и пара симлинков. Ну и доки еще в довесок. Под нее обязательно нужно отдельный директорий выделять.

IceD

Я тут подумал - вот надумаю сменить работу, приду на какую-нить контору админом, а там гоболинукс. Нда...

IceD

2IceD ну выделил я целый каталог, и что теперь? :)

Я тут на досуге решил позырить, что твориться у меня в директориях /lib, /usr/lib (почти свежеустановленная RedHat 9). Ой, мутер! по 2-3 (а то и по 5) раз прописана одна и таже либа (libldap, например). А в /usr/lib так ваще я нашел дружно оплеванную и преданную анафеме всеми правоверными пингвинистами идею /usr/lib/<pkgname>. А уж скока симлинков типа libBlahBlahBlah.so.X.Y.Z -> libBlahBlahBlah.so.X1.Y1.Z1.

И тут я задумался. А хорошо это или плохо. Те кто считают, что это хорошо, удобно, так и надо (ибо это UNIX-way, не для ламерья все это виндуозного) -- не читайте дальше, поэкономте время (успеете еще по 3 раза написать "Gobo -- ацтой").

А для оставшихся напомню про dll hell в Windows. Так вот, то, что деется в (выражусь осторожно) довольно неплохом дистре есть типичный lib hell (особенно, если речь идет не о серваке, а desktop'ной машине, куда и игрульку поставить хочется, и с какиь-нить софтом поэкспериментировать и. т. д).

Посмотрите, что предлагают гайсы из Gobo (сорри за длинный пост, я не удержался и процитировал их пряма тут)

------------------------------ In GoboLinux, each program lives in its own directory, like this:

/Programs/Netkit-Base/0.17/bin/ping /Programs/LibPNG/1.2.5/lib/libpng.so.3 (and so on)

For each category of files, there is a directory under /System/Links collecting symlinks of the programs' files.

/System/Links/Executables/ping /System/Links/Libraries/libpng.so.3 (and so on)

Traditional Unix paths are also symlinks, to the /System/Links strucutre:

/bin -> /System/Links/Executables /usr/bin -> /System/Links/Executables /usr/lib -> /System/Links/Libraries (and so on)

This system provides many niceties: it makes it easy for different versions of libraries to coexist, it's easy to uninstall software compiled from source, and it does not require a database-oriented package management system. In case you're wondering, we do have a basic dependency tracking system going. Other unusual stuff: it doesn't use either SysV nor BSD bootscripts (in favor of a simpler, custom system); the default user #0 is named "gobo" instead of "root" (just because -- you can set it to anything you like). ----------------------------------

Не надо кричать про отстойность Windows, и про то, что все, что от винды -- ацтой. С hell'ом они (мастдайцы) борются неплохо (см win2k, XP, .NET assemlies). Gobo'вцы просто предложили способ, как манагить пакеты БЕЗ package manager'а. Хорошо это или плохо -- не знаю. Но проблема есть и ее как-то решать надо.

dimfair

> А что rpm -e foo быстрее работает ? Или он файлы быстрее чем find ищет ? А зависимости с ключем -e он проверяет ?

Sun-ch ну ты в компот-то не сцы, а то последнее уважение растеряешь. Совсем дремучим стал.. Конечно быстрее работает, он же не занимается обнюхиванием каждого файла на диске; у него список файлов в пакете есть, их по списку и выносит. Зависимости ессно проверяет, попробуй на досуге вынести glibc :-)

> А чем locate не нравиться при поиске?

Тем же чем и find. Нет 100% гарантии что ты удалишь только то, что принадлежит этому пакету (или наоборот, забудешь чего)

Кроме того, база locate обновляется раз в сутки, если специально руками не подкручивать.