Re: [devel] Re: [mdk-re] /etc/emacs/site-start.d

[Ivan Zakharyaschev <vanyaz@mccme.ru>]

	Hello!

Я отчасти поддерживаю идею об использовании /etc/emacs/site-start.d -- по
аналогии с, например, /etc/profile.d; сравнение с старт-стоп скриптами не
очень подхолит, так как они настраивают сервер, а profile задает
конфигурацию для отдельного пользователя.

Удобство такой директории понятно: не нужно лезть в один файл, чтобы
что-то добавить, достаточно просто положить в директорию.

Но есть, по-моему, и большие неудобства. Они связаны как раз с разницей
между initscripts и profile: раз это конфигурация для пользователя, то
неплохо бы каждому отдельному пользователю иметь контроль над тем, что у
него будет грузиться, а что нет. А тут получается, как администратор
скажет, так всем и жить.

В случае с profile это неудобство почти незаметно. Во-первых,
администратор может не очень хотеть, чтобы что-то из profile не было
исполнено при заходе пользователя. Во-вторых, все скрипты из profile
исполняются почти незаметно по времени -- а вот время запуска Emacs
хотелось не увеличивать, тем более если оно тратится на то, чтобы
загрузить что-то, что тебе и не нужно.

Можно попробовать решить эту проблему, создав структуру директорий,
похожую на ту, что есть в initscripts: есть /etc/emacs/site-start.d/, где
лежат скрипты, но не выполняются, и у каждого есть ~/.emacs/site-start.d/,
куда кладутся ссылки на реальные скрипты из /etc/emacs/site-start.d/
(можно будет их включать/выключать у разных пользователей, как и сервисы
в разных runlevels). Не слишком ли это громоздко?


Кстати, похожие неудобства есть при работе с системой альтернатив --
хотелось бы, чтобы каждый пользователь мог сам выбрать себе одну из
альтернатив. Без помощи администратора.

Например, почему обычный пользователь, желающий напечатать что-то из
Netscape, должен обладать правами root, чтобы осуществить свое желание? А
что если в то же время, на другом терминале на той же машине другой
пользователь захочет печатать из Mozilla? Как им поделить Fontmap?

И с компиляторами то же самое. С одной стороны мы призываем заниматься
сборкой под простым пользователем , но с другой стороны мы этому простому
пользователю не даем полную мощь в использовании инструментов сборки --
чтобы начать использовать альтернативный компилятор, нужно быть root'ом.
Конечно, есть обходные пути... но я говорю про полную мощь. А так эти
альтернативы на компиляторы начинают выглядить странно и вдвойне
бесполезно: тот, кому они нужны, не может ими управлять, а управлять ими
может тот (root), кому они не нужны. :-(

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

А мне в связи с этим вспомнились разговоры про похожесть файловой системы
и сервера базы данных. Если бы файловая система предоставлялась сервером
баз данных, то была бы сама собой разумеющейся возможность увидеть одни и
те же данные (например, /usr/bin/gcc) разным пользователям по-разному --
один из основных принципов устройства сервера баз данных. И вообще
появилась бы большая гибкость в работе с файловой системой! И
тормознутость. А изветстны ли какие-нибудь проекты на эту тему?

-- 
Best regards,
	Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel