Re:

Если рубить с корней, то что там делается в ветвях - совершенно необязательно знать. В данном случае (разрешение на запуск только определенных приложений) достаточно средств типа chroot/vserver + явного указания мест, откуда что-либо может быть запущено. Моё предложение о решении этой задачи за деньги остается в силе.

2 AlexM
Если ставить noexec на $HOME то отпадает всякая необходимость в policy на запуск ~/bin/startMyHackerXprog.sh. О чём, собственно, разговор тут и идёт - о том, что секьюрити должна заниматься OS а не WM или DE.

> И Вы все-таки мне скажите - а где в формате KDE хранится timestamp?

1) Это дата модификации файла конфигурации.
2) А нахрена это нужно?
2.1) Если нужно следить, что поменял пользователь, то
а) используем kiosk mode
б) прикручиваем журналирование к KConfig.

Теперь скажите, есть в Gnome полноценный аналог KConfig с возможностью трансляции вручную изменённого параметра для запущенной программы. Хотя какой дурак будет вручную разгребать этот хлам в XML? :)

> Если бы Вы каким-то способом _не_допустили_ появления опечаток - вот тогда можно было бы сравнивать.

В полях ввода Konqueror, KMail, KWord, Kopete есть подчёркивание ошибочных слов. Это куда как более эффективный способ борьбы с опечатками. Эх, если б у всех так было... :)

> xsltproc - утилита командной строки. Универсальный обработчик XML с неограниченной мощностью. Для всех, как говорится, веков и народов. В _некоторых_ случаях и grep сойдет. Опять же, perl почти всегда под рукой - а там есть парсер...

Вы что, издеваетесь? Это как долго нужно надрачиваться писать XSLT и научится терпеливо ждать тормознутого expat в Перле, чтобы такое советовать? :(

> Это уже не твое личное дело. Так как твоя прога имеет зависимость от GPL'ной Qt, то ты не можешь выпустить ее не под GPL.

Да, не могу. Но я могу ее вообще не выпускать, ни под GPL, ни под какой-либо др.лицензией. И использовать для разработки своего софта GPL-версию Qt. См. GPL.

> Тролли продадут лицензию - но она будет применима только к тем программам, которые разработаны в период ее действия (и они имеют на это право). То есть на твою GPL'ную софтину она не распространяется.

После того, как я куплю у них лицензию, я могу распространять с помощью нее любой софт, на которые у меня есть авторские и имущественные права, произведенный мною в любое время, выпущенный или нет ранее под любыми лицензиями. Эти права мне дает законодательство, а не лицензия Trolltech.

> Хотя понятно, конечно, что спор чисто теоретический. Ибо что-то доказать тролли никогда не смогут ("а мы прогу за день написали, как лицензию получили, вот!"), так что кому не нужен их саппорт - могут пользоваться таким методом и спать спокойно =)

Конечно. Но даже если и докажут, то что они могут сделать? Лицензию-то я уже купил.

Здесь второй аспект важен. Если делать так, как говорите вы, то не будет возможно вообще какое-либо портирование софта на Qt. Не думаю, что это в интересах тролей... Так что то, что у них написано в факе - чушь.

>> С ростом количества приложений, которые нужно _разрешить_ запускать пользователю, и/или их сложности количество точек, куда надо пойти и поправить (причём править согласованно!) растет, очень сильно (~по экспоненте?).

> Не совсем так. Оно все-таки растет линейно.

Линейно не получается никак. Мы имеем многомерный куб. Количество осей координат == количество приложений. Протяжённость вдоль каждой оси == количество настроек для этого приложения в gconf (а туда суют не только конфигурацию, но и всякий run-time мусор, например, позиция + размер окна).

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

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

Получается, что единственный способ дать хоть какую-то надежду -- это 100% по охвату тестирование, что не реально. (Даже одну нетриаиальную программу невозможно протестировать с охватом 100% во всех условиях, а тут комбинация всех программ во всех условиях).

> За это надо бороться. Нужна полиси (типа HIG - только про блокировку). Если приложение поставляется с гномом - оно должно быть гарантированно управляемым

Полиси не гарантирует управляемости. Типичный пример -- HIG, который не просто не гарантирует usability, но и временами просто стоит поперёк горла, особенно когда начинается "насиляние" его буквы, а не духа (Вы помните, историю с "закрывать диалоги поиска по Esc"?)

И ещё про "Если приложение поставляется с гномом - оно должно быть гарантированно управляемым": допустим, оно будет управляемым в пределах этого несозанного HIG-аналога про Lockdown. Но будет ли этого достаточно?

Ведь мы не просто развлекаемся "кто сильнее пользователя запрёт в круга позволенных задач"...

Нам надо это сделать не нарушая его (пользователя) рабочий режим (способность делать свою работу) и производительность.

И тут я согласен с Dselect -- решать это на уровне десктопа -- как минимум не эффективно. Часто -- не возможно.

to svu:
Я года 2 назад слышал, что _максимальная_ скорость интерпретирования
XML - около 300k в секунду. Тогда же слышал обо всяких попытках
хардварно ускорить интерпретацию этого монстра.
Отсюта вывод - использование XML возможно только
если совсем приперло и нет другого выхода.

С другой стороны - те фишки, о которых Вы говорите, получаются в два-три шага:
1) Часть конфигов - в /etc, часть - в ~/.progname. То что в /etc - имеет приоритет. Возможно, в /etc в конфигах нужно предусмотреть отдельные настройки для разных пользователей.

2) Читать конфиги - через либу типа PAM - чтобы можно было подставить
любой backend (или даже сделать их stackable)

3) А дерево получается и в .ini-файле:
[section0]
a=1
[section1]
b=1
[section1.subsection0]
include=ldap://ldap.server/o=org,c=ru/filter=(&(objecctclass=........)(..... ))
f=1

Из опыта - где бы я ни встречал XML - везде он не в тему.
Наверное, он нужен, но мне таких задач решать не приходилось.
Для человека он неудобен - много лишенй информации.
Для машины неудобен - медленно парсить.
Менее устойчив с повреждениям чем "обычный" конфиг.
Простыми скриптами не поправить.
Из-за этого получается - в конторах в качестве конфигов он тоже неприменим.
И даже diff ему делать неудобно.

Так gnome и есть OS. По крайней мере стремится быть таковой.

2 svu: Афаир gnome позиционируется как кросс-платформенное решение?

> Так же можно сказать, что сравнивая вин 95 и вин ХР разницы никакой.

Да есть разница, даже с точки зрения пользователя.

> Те же окна, те-же функции. А вот если немного полазить по интернету с помощью огнептица, то сразу станет ясно в чём разница.

И в чем же?? Я особой не заметил. Как не работало с многими сайтами, так и не работает. Как тормозило, так и тормозит.

>Из опыта - где бы я ни встречал XML - везде он не в
>тему.
Jabber? XML дает возможность прозрачно расширять протокол. ИМХО просто все забыли что XML прежде всего eXtendable, а уж потом читаемый и древообразный... но в любом случае XML избыточен по основе своей :-(.

>> Так же можно сказать, что сравнивая вин 95 и вин ХР
>разницы никакой.
>Да есть разница, даже с точки зрения пользователя.

В чем же? Как использовал для запуска игрушек - так и использую. Как тормозило и глючило и вирусами заражалось, так и тормозит и глючит и вирусами заражается.

>И в чем же?? Я особой не заметил. Как не работало с
>многими сайтами, так и не работает. Как тормозило, так
>и тормозит.
Смотрел не туда.

> Это не совсем то же самое.

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

> А предложенный Вами способ - это все равно что трогаться с взведенным ручником

Я уже сказал - мой метод утопичен. Он реален только в том случае, если компутер научится читать мысли - угадывать, какое слово человек хочет набрать. При существующей работе (со словарями) действительно может получаться ручник.

Но это все мало относится к конфигурации. Она - не длинный текст, а набор очень коротких и очень критичных данных. Поэтому скорость тут менее критична, чем правильность.

>> Так же можно сказать, что сравнивая вин 95 и вин ХР разницы никакой. >Да есть разница, даже с точки зрения пользователя. >> Те же окна, те-же функции. А вот если немного полазить по интернету с помощью огнептица, то сразу станет ясно в чём разница. >И в чем же?? Я особой не заметил. Как не работало с многими сайтами, так и не работает. Как тормозило, так и тормозит. Причём тут Мозилла, а точнее её движок Геско к отображению? Если в веб-девелопера кривые руки, то браузер не виноват. К стати, никогда не замечал, как ИЕ отображает таблицы? Пока ВСЯ таблица не загрузится, она не отображается. Мозилла рисует сразу, что загрузилось. Из изменений в последних релизах Фаерлиса - удобное добавление и редактирвоание букмарков, новые экстеншены, улучшающие юзабельность и добавляющие просто таки замечательные удобства, как для разработчика страниц, так и для простого пользователя. Всегда, если хорошо присмотреться, можн найти много интересного.

re: eXOR
Я про Jabber ничего не знаю - но слышал что это "XML раутер".
Из чего делаю вывод, что он просто пересылает какой-то текст
от одной машины/программы к другой.
А что с этими данными делать - решает клиент.

Так а чего клиету просто не игнорировать поля, которых он не понимает?
Вот вам и расширяемый протокол. Или я чего-то не знаю про Jabber/XML?

забыл подписаться под предыдущим постом

Вся эта пламенная речь в защиту текстовых конфигов - очень убедительна. Но есть несколько моментов:

> внесения требуемых _тебе_ комментариев

Как раз XML-то тут очень даже подходит (правда, не в текущем DTD gconf). Пользовательские комментарии прекрасно складываются в какой-нибудь атрибут comment="...". Это не сложно добавить - правда, придется формат и API расширить. А вот как Вы это сделаете с текстовым форматом - да так, чтобы гуевые тулзовины это понимали и давали редактировать? Будете вводить "псевдо-комментарии" (с одной стороный, игнорируемые конфигурируемой прогой, с другой - понимаемые гуем)? Скажем так, безотносительно редактора - _требуется_ иметь возможность гуевого редактирования, с рюшечками и пр. vi, увы, для чайников плохо подходит в качестве редактора конфигурации. Систему, конфигурируемую только через vi, продавать/внедрять (в смысле убеждения менагеров) сложнее, чем систему с красивой конфигурялкой - Вы, надеюсь, это понимаете.

> внятной версионизации с внятными же комментариями на каждую версию

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

> Вы будете спорить, что в части текстового редактирования нормальные текстовые редакторы на порядки удобнее этих вот недоделанных gconf-editor'ов

Никогда. Но я буду спорить с тем, что редактирование конфигурации == редактирование текста.

> потому что в текстовом редакторе я могу сделать undo, могу проскакать обратно курсором по тем местам, по которым я уже скакал, н-р, ища некоторый ключ (см. incremental search) итп

Поиск (в любыми наворотами) нужен - это правда, это просто недоделка в gconf-editor - все остальное мне ни разу не требовалось в regedit, в gconf-editor (да и в vi httpd.conf тоже). Вы же конфигурацию редактируете, а не статью и не полугодовой отчет!

> Хотите, я дома эксперимент поставлю, посажу семидесятишестилетнюю бабушку разбираться с этой "интуитивно-понятной" тулзой разбираться?

Если бабушка работала с компутерами хотя бы годик, она поймет gconf-editor. Если у Вас есть такая бабушка - попробуйте провести эксперимент.

> не из-за интуитивной понятности, а, скорее, из-за более низкого стартового порога

А это не коррелирующие вещи?

> мы ориентируемся на дебилов, которые слаще морковки ничего не едали, а _удобство_ работы этих самых дебилов нас не волнует совершенно

Ориентация на пользователя (менеджера, клерка, ...) Джонни как раз и означает (мне так казалось) - сделать так, чтобы Джонни было удобно. Возможно, при этом крутому админу Питу или могучему девелоперу Бетти будет немного жать в плечах. Или Вы понимаете слово "ориентация" как-то по другому? (такой скользкий каламбур получился:)

> А нахрена это нужно?

Насколько я понимаю, это участвует в работе механизма нотификации. Хотя, надо код посмотреть. Вообще, вопрос общего характера - как удобно ассоциировать мета-данные со значением конфигурационной переменной.

> Если нужно следить, что поменял пользователь, то а) используем kiosk mode б) прикручиваем журналирование к KConfig.

Нужно не одному пользователю следить за другим пользователем (точнее, это тоже нужно, но я не об этом) - нужно, чтобы одна прога устанавливала значения конфигурации, а другая СРАЗУ (если попросит, конечно) получала эти значения. При чем тут kiosk и журналирование?

> есть в Gnome полноценный аналог KConfig с возможностью трансляции вручную изменённого параметра для запущенной программы. Хотя какой дурак будет вручную разгребать этот хлам в XML? :)

Извините, не понял, что такое "возможностью трансляции вручную изменённого параметра для запущенной программы". Можно подробнее? А хлам в XML разбирался и разбирается при помощи XQuery и/или XSLT (смотря что нужно).

> Вы что, издеваетесь? Это как долго нужно надрачиваться писать XSLT и научится терпеливо ждать тормознутого expat в Перле, чтобы такое советовать? :(

Конечно, немного издеваюсь, это есть:) Тормознутость expat меня мало колышет - на средних размеров XML файле мой центрино 1.6 работает со скоростью, мало отличимой от скорости grep (т.е. практически мгновенно). XSLT - да, имеет смысл городить только для повторяющихся задач - для одного запросика это перебор. Конечно, это не sed/grep/awk/... Но, как я сказал, в _некоторых_ случаях (особенно если файл нормально синдентирован), grep тоже может помочь. Теперь задачка. Попробуйте взять fvwmrc, где перед разными переменными стоят комментарии типа

# modified jonny 1.1.2004 # modified betty 1.2.2004

И выдайте мне список переменных конфигурации, которые были модифицированны jonny в этом году. Очевидно, вы тут же делаете рывок в сторону перла (или, в крайнем случае, awk - потому как grep уже не спасает). А я буду делать xslt (разумеется, мой xml содержит всю эту информацию в удобном виде таймстампов). Вы уверены, что напишете перловую программу быстрее, чем я xslt?

> Линейно не получается никак. Мы имеем многомерный куб. Количество осей координат == количество приложений. Протяжённость вдоль каждой оси == количество настроек для этого приложения в gconf (а туда суют не только конфигурацию, но и всякий run-time мусор, например, позиция + размер окна).

Чего-то я не понял. Зачем вы рассматриваете все возможные сочетания конфигурационных параметров? Что это Вам дает?

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

Пространство имен gconf и иерархия пермишенов - это два разных пространства имен. Второе управляет первым. А в gconf, конечно, не должно быть такого - кросс-зависимости ключей. Да и нет. Если пользователю запретили некий permission (допустим, названный a.b - это означает, что контролируемые им ключи /x1/x2/x3 и y1/y2/y3/y4 недоступны для редактирования). Но это, повторяю, все мои личные мечты - этого там сейчас и рядом нет.

> Полиси не гарантирует управляемости. Типичный пример -- HIG, который не просто не гарантирует usability, но и временами просто стоит поперёк горла, особенно когда начинается "насиляние" его буквы, а не духа (Вы помните, историю с "закрывать диалоги поиска по Esc"?)

И тем не менее - будете ли Вы спорить с тем, что после введения HIG (от которого я тоже не в восторге - я вообще не очень люблю жесткую дисциплину) интерфейс гнома стал более ровным, консистентным?

> И ещё про "Если приложение поставляется с гномом - оно должно быть гарантированно управляемым": допустим, оно будет управляемым в пределах этого несозанного HIG-аналога про Lockdown. Но будет ли этого достаточно?

До тех пор, пока пользователь ограничен "сертифицированным" приложениями гнома - да. Если нет - нужно ужесточать либо полиси, либо сертификацию.

> Нам надо это сделать не нарушая его (пользователя) рабочий режим (способность делать свою работу) и производительность.

Разумеется. Поэтому подобная полиси должна быть очень продуманной. Топором можно навалять...

> И тут я согласен с Dselect -- решать это на уровне десктопа -- как минимум не эффективно. Часто -- не возможно.

Скажем так, для меня еще может быть вопрос в том, возможно или нет. То, что на уровне десктопа это эффективно - я убежден. Потому что на уровне десктопа полиси формулируется именно в терминах десктопа, а не в терминах каких-то функций (какого дьявола админ должен знать имена функций, которые входят в xlib API?) или файлов (при чем тут файлы, если я хочу запретить смену скринейвера?).

> 1) Часть конфигов - в /etc, часть - в ~/.progname. То что в /etc - имеет приоритет. Возможно, в /etc в конфигах нужно предусмотреть отдельные настройки для разных пользователей

А если машин много?

> 2) Читать конфиги - через либу типа PAM - чтобы можно было подставить любой backend (или даже сделать их stackable)

Именно это и есть gconf. И тогда пункты 1 и 3 - это уже детали реализации одного из бекендов.

> 3) А дерево получается и в .ini-файле:

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

> Для человека он неудобен - много лишенй информации.

Хорошо индентированный, хорошо сбалансированный, не слишком больших размеров и не слишком большой глубины (обычно конфиги именно такие) - прекрасно читается, даже в vi. А если еще есть тулзовинка, сбоку покажывающая дерево (как в разных жабских IDE) - совсем хорошо.

> Для машины неудобен - медленно парсить.

Для конфигурации не критично - размер файлов умеренный, читаются не очень часто (gconfd все-таки кэширует, насолько я знаю)

> Менее устойчив с повреждениям чем "обычный" конфиг.

Испортить можно все. Хотя да, тут один символ может весь конфиг порушить, это правда.

> Простыми скриптами не поправить.

Смотря что считать простым скриптом. См. выше задачку про модифицированные jonny значения.

> Из-за этого получается - в конторах в качестве конфигов он тоже неприменим.

Если конфиги предназначены в первую очередь для ручного редактирования - да. Если конфиги предназначены для работы с соотв. тулзами - нет. Кстати, gconf файлы действительно не предназначены - все должно происходить через gconfd (или Вам придется его перезапускать - вроде, он не детектирует подхаченных файлов).

> И даже diff ему делать неудобно.

Видел я где-то xmldiff...

Про конфиг

>Хорошо индентированный, хорошо сбалансированный, не слишком больших >размеров и не слишком большой глубины (обычно конфиги именно такие) - >прекрасно читается, даже в vi. А если еще есть тулзовинка, сбоку >покажывающая дерево (как в разных жабских IDE) - совсем хорошо.

Неужели ЭТО: <entry name="layouts" mtime="1083877490" type="list" ltype="string"> <li type="string"> <stringvalue>us</stringvalue> </li> <li type="string"> <stringvalue>ru winkeys</stringvalue> </li> </entry>

Удобнее, чем: layouts="us,ru winkeys"

???

>А если машин много?

Тогда у каждой в /etc: include=/nfsserver/config.conf

>Для конфигурации не критично - размер файлов умеренный, читаются не >очень часто (gconfd все-таки кэширует, насолько я знаю)

Конечно - если машина больше ничем не занимается, а только парсит XML-config.

>Смотря что считать простым скриптом. См. выше задачку про >модифицированные jonny значения.

Не надо усложнять простое. Когда надо просто - пусть будет просто. Мне ни разу не понадобилась ТАКАЯ история изменений конфига. А вот закомментить часть его и переписать её заново - постоянно. Ну а если надо что-то сложное - какой-нибудь CVS-backend и все.

>Если конфиги предназначены в первую очередь для ручного >редактирования - да. Если конфиги предназначены для работы с соотв. >тулзами - нет. Кстати, gconf файлы действительно не предназначены - все >должно происходить через gconfd (или Вам придется его перезапускать - >вроде, он не детектирует подхаченных файлов).

Вот опять - кто-то решил - как и что мне делать. Хотя вполне мог бы оставить мне больше свободы - просто чуть больше подумав. А если я хочу все что в /etc - руками а все что в ~/.progname - тулзой? А если для каждого пользователя у меня автоматически генерятся настройки при некоторых условиях и надо парсить его готовые файлы своими скриптами? А если мне надо просто помочь пользователю, например, поменять цвет бэкграунда? Я что - должен помнить как там этот параметр называется (глазами в XML вообще нечего соваться)?

>Видел я где-то xmldiff... А xmlpatch , xmled , vmlvim, xmlcat, ...... и т.д. где взять?

Re:

Ну, это, в общем, и так понятно, что /home должен быть с noexec в такой системе. Или, мы, извините, ограничиваем количество программ которые могут быть запущены пользователем, или не ограничиваем :-).

Re:

> Как тормозило, так и тормозит.

Хех... Интересный удар по мозилке. Нет, я знаю, что опера визуально быстрее (почти везде, при условии _хорошего_ интернета). Но "тормозит" - по-моему, сильно :-).

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

> Удобнее, чем: layouts="us,ru winkeys"

Если для по-быстрому да по-простому, конечно, Ваш вариант лучше. Только с машинно-гуевым редактированием проблемы (в смысле - как гуевая конфигурялка должна поступать с комментариями, должна ли она их понимать и различать, автоматически добавлять history etc.?) Опять же, проблема с атрибутами у значений.

> Тогда у каждой в /etc: include=/nfsserver/config.conf

В общем, в gconf немного похоже. Там дефолтные значения в /etc живут. Только для сети существующий бекенд не предназначен - нужен совсем другой, LDAPовский, недоделанный

> Конечно - если машина больше ничем не занимается, а только парсит XML-config.

Я же сказал - gconfd кэширует, так что и на другую деятельность процессора хватает:)

> Не надо усложнять простое. Когда надо просто - пусть будет просто

Да, мой пример избыточно сложен. Я просто хотел показать, что бывают ситуации, когда у значения могут понадобиться атрибуты. И в инифайле name=value это проблема. А про CVS backend - мысль смешная, надо подумать:)

> А если я хочу все что в /etc - руками а все что в ~/.progname - тулзой?

Тогда это будет называться бардак:)

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

Нет проблем! gconftool прекрасно вписывается в любые скрипты! И как getter и как setter. Вы знаете, какое сообщение я выкидываю пользователю, когда у него клава не инициализируется?

If you report this situation as a bug, please include:

- The result of <b>xprop -root | grep XKB</b>

- The result of <b>gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb</b>

И ничего - народ прекрасно справляется!

> А xmlpatch , xmled , vmlvim, xmlcat, ...... и т.д. где взять?

xmlpatch - кажется, тоже был (но не уверен). В принципе (если индентация нормальная) и обычный сгодится.

% cd /usr/bin

% ln -s cat xmlcat

% ln -s ed xmled

% ln -s vim xmlvim

> Или, мы, извините, ограничиваем количество программ которые могут быть запущены пользователем, или не ограничиваем :-).

Я изначально не хотел этого делать. Я хотел только запретить менять скринсейвер:)

> И тем не менее - будете ли Вы спорить с тем, что после введения HIG (от которого я тоже не в восторге - я вообще не очень люблю жесткую дисциплину) интерфейс гнома стал более ровным, консистентным?

Буду. Остается жесткое впечатление аляповатости. Причём чем дальше, тем хуже - ориентация на идиотов никогда ни к чему хорошему не приводила. 1.4 оставлял после себя _гораздо_ более приятное впечатление. На работе сижу на 2.2.2 (SuSE), дома 2.4.1 (Debian) - а вот от 2.6 плеваться хочется, причём что самое интересное, - сложно сказать от чего именно, но общее впечатление сырого подвала остаётся, будем смотреть что дальше будет. Ощущение консистентности остаётся после KDE, но я почти всё использую с GTK+/GNOME, поэтому пользую GNOME + любовно оттюненный fvwm2.

> Буду. Остается жесткое впечатление аляповатости

Ну, значит, это дело вкуса. Я гном 1.4 больше любил в смысле гибкости - но 2.6 по моему мнению куда консистентней.

> общее впечатление сырого подвала остаётся,

Я же не про сухость или сырость. А про то, чтобы во всех углах подвала было одинаково (либо сухо, либо сыро:).

> любовно оттюненный fvwm2.

Я просто не в курсе - а fvwm2 хорошо дружит с freedesktop.org-овскими стандартами WM? Проблем не возникает?

> Ну, значит, это дело вкуса. Я гном 1.4 больше любил в смысле гибкости - но 2.6 по моему мнению куда консистентней.

Угу, был нормальный "Зенит", а сделали тупую Олимпусовскую "мыльницу".

>Я же не про сухость или сырость. А про то, чтобы во всех углах подвала было одинаково (либо сухо, либо сыро:).

Дети - в школе, а для взрослых людей есть взрослый мир. А получается, что взрослого человека пытаются посадить в песочницу. Не знаю, может в США такие взрослые, но от Европы у меня осталось куда как лучшее впечатление, - по крайней мере идиотов не попадалось (может искал плохо ;-).

> Я просто не в курсе - а fvwm2 хорошо дружит с freedesktop.org-овскими стандартами WM? Проблем не возникает?

EWMH & freedesktop.org он, IMHO, поддерживает лучше всех, до 2.5.9 были глюки с задержкой при старте из под GNOME, но в 2.5.10 вроде поправили.

> Угу, был нормальный "Зенит", а сделали тупую Олимпусовскую "мыльницу".

Кто более успешен коммерчески - Зенит или Олипус?;)

> Дети - в школе, а для взрослых людей есть взрослый мир. А получается, что взрослого человека пытаются посадить в песочницу.

А Вы не замечаете, что инфантилизм - это просто маркетинго-дизайнерский хит нашего времени? GUI почти всех нынешних поп-ОС такие немножечко игрушечные. И раскрасочка соответствующая...

За инфу про fvwm2 спасибо.

>> Нам надо это сделать не нарушая его (пользователя) рабочий режим (способность делать свою работу) и производительность

>> И тут я согласен с Dselect -- решать это на уровне десктопа -- как минимум не эффективно. Часто -- не возможно.

> Скажем так, для меня еще может быть вопрос в том, возможно или нет. То, что на уровне десктопа это эффективно - я убежден. Потому что на уровне десктопа полиси формулируется именно в терминах десктопа, а не в терминах каких-то функций (какого дьявола админ должен знать имена функций, которые входят в xlib API?) или файлов (при чем тут файлы, если я хочу запретить смену скринейвера?).

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

Условия задачи: я программист в программистской конторе. Вы -- в этой же конторе админ. По какой-то причине Вам надо запретить мне менять скринсейвер.

Дополнительные ограничения: в результате вашего обкусывания мне прав я всё-таки должен иметь возможность делать свою работу.

Вы видите какое-нибудь решение этой задачи, кроме административно-командного (т.е. подключить к решению моё начальство, дабы оно спустило мне сверху приказ о недопустимости смены скринсейвера?)?

Да нет же, AlexM, ты насчёт noexec, видать, не так понял. Мой тезис был просто тот, что, на реальном рабочем десктопе, если ядро даёт мне права на запуск проги, то обязательно найдётся какая-нибудь лазейка запустить её в обход policy DE.

И, разумеется, я не имею в виду крайние случаи, когда, к примеру, запрещён логин на всё кроме ttyd* и логин-шеллом стоит /usr/bin/pppd :-)

>% ln -s cat xmlcat

>% ln -s ed xmled

>% ln -s vim xmlvim

Вообще-то, когда я говорил
"А xmlpatch , xmled , vmlvim, xmlcat, ...... и т.д. где взять?" - я шутил и намекал,
что плохо пользоваться форматом, с которым неудобно работать
стандартными средствами. Но я понимаю, что и Вы пошутили ....

>Нет проблем! gconftool прекрасно вписывается в любые скрипты!

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

Сколько контор с мощным "IT-отделом" я видел - у всех системы отличались
друг от друга разительно. И уж тем более от конфигураций, предлагаемых
"стандартной поставкой". Везде разные схемы аутетнтификации,
раздачи дискового места, бэкапа и т.д. Свои приказы и правила на этот счет.
А Гномовцы (как и Микрософт) предполагают, что все будут как один -
строем ходить (ну, почти).

Все эти гуевые приблуды - это ХОРОШО. Но только до тех пор, пока они
не мешают (а лучше помогают) управлять большой системой крайне
небольшим коллективом админов. На мой взгляд, XML-формат конфигов
это огромный минус в гибкости.

Насчет gconfd - я не знаю чем он занимается - возможно он и пытается
минимизировать некоторые минусы начального проектирования Гнома
(XML-конфиги), но врядли это может получится до конца.

Для того чтобы стать маркетинговым хитом для начала неплохо бы было хотя бы самые дурацкие глюки вылизать, а не заниматься всякой, извиняюсь, околотеоретической хернёй (ничего личного). Я до сих пор не могу забыть про выпадающие меню, где половина на-русском, а половина на английском :-))

> Кто более успешен коммерчески - Зенит или Олипус?;)

К счастью, существуют и профессиональные фотоапараты. :-) Посмотрите на CDE - есть GUI, но есть и Administration & _Advanced_ User Guide - оказыватся всё можно прекрасно скриптовать без ущерба для функциональности для dumb luser. Одна их панель (которая по сути является скриптом для dtwm) чего стоит.

> А Вы не замечаете, что инфантилизм - это просто маркетинго-дизайнерский хит нашего времени? GUI почти всех нынешних поп-ОС такие немножечко игрушечные. И раскрасочка соответствующая...

Увы и ах. "О дивный новый мир" (C) Олдос Хаксли, в действии - советую к прочтению. Кстати, с каких это пор *NIX стал поп-ОС ?

> За инфу про fvwm2 спасибо.

Незачто. Вообще - шикарный WM. Только, plz, без holy wars. ;-)

Re:

> Как раз XML-то тут очень даже подходит (правда, не в текущем DTD gconf).

То есть, так и запишем: в текущем своем состоянии gconf для этого непригоден. Вечно перспективный, блин.

> Пользовательские комментарии прекрасно складываются в какой-нибудь атрибут comment="...". Это не сложно добавить - правда, придется формат и API расширить.

:-)

> Будете вводить "псевдо-комментарии" (с одной стороный, игнорируемые конфигурируемой прогой, с другой - понимаемые гуем)?

Нет, слава Богу, для этого есть и более здравые решения. Например, такие, когда комментарии сохраняются безо всяких проблем (то есть, приложение _внутри себя_ строит какое ему интересно там дерево, со всякими отступлениями итп, а при записи просто пишет _все_ данные в том порядке, в котором они читались, включая конфиги. Кажется, нечто подобное было в Ясте реализовано).

> Поиск (в любыми наворотами) нужен - это правда, это просто недоделка в gconf-editor - все остальное мне ни разу не требовалось в regedit, в gconf-editor (да и в vi httpd.conf тоже). Вы же конфигурацию редактируете, а не статью и не полугодовой отчет!

(Сдерживая злую иронию) а вам никогда не приходилось искать ключ по его названию. Точнее даже, не по названию, а по тому, как вы думаете, что он может называться? Мне приходилось. Что в gconf-editor, что в regedit - это паршивое занятие, потому что точно никогда не знаешь, то, что найдено - это то, что нужно, или будет нечто более подходящее по смыслу.

> Если бабушка работала с компутерами хотя бы годик, она поймет gconf-editor. Если у Вас есть такая бабушка - попробуйте провести эксперимент.

А если не работала? А опыт работы с компьютерами в бытность её глав.бухом областного вторчермета, - он считается за опыт? :-) И, потом, откуда эти "периодические" цензы взяты, про год? Это где-нибудь в GNOME HIG написано, или Вы сами из головы это сейчас выдумали? Изначально, напомню, речь шла об "интуитивной понятности", т.е. "интуиция" - единственное и достаточное условие для "понятности", нет?

> не из-за интуитивной понятности, а, скорее, из-за более низкого стартового порога

> А это не коррелирующие вещи?

Отнюдь. Оконный ГУЙ сам по себе не является ни интуитивным, ни понятным. Это просто некоторая метафора, которую достаточно просто объяснять неподготовленному человеку, потому что всегда можно оперировать знакомыми всем [местным жителям] понятиями стеклянных пластинок и изображений на них. Попробуйте объяснить аналогию с окнами, человеку, который никогда не видел стекла и я посмотрю на Ваши успехи.

Кроме того, нужно понимать, что существует отлично наблюдаемый эффект импринтинга. То есть, если человек уже видел виндоус, и это было его первым знакомством с компьютером, то все последующие "виндоус-подобные интерфейсы" он будет воспринимать легче. Это, отнюдь не означает, что эти интерфейсы будут "понятнее", или с ними будет "удобнее работать". Это просто означает уменьшение _первоначального_ психического дискомфорта. А скорость обучения пользования той же 1C в сравнении с Бэстом была _меньше_ (повторяю, в 97 году, когда я сам видел (в качестве админа), как проводятся курсы).

> мы ориентируемся на дебилов, которые слаще морковки ничего не едали, а _удобство_ работы этих самых дебилов нас не волнует совершенно

Повторяю: мне незнакомы люди, которые были бы необучаемы и при этом работали бы в офисах. И "удобно" в данном случае неприменимо. Скорее "легче привыкнуть и меньше страдать при привыкании".

Собственно говоря, унифицированный интерфейс пользователя _нужен_ ; нужен по многим причинам, в частности, для переиспользования имеющихся у пользователя навыков при смене инструментария и, как следствие, уменьшения времени обучения и сглаживания психологического дискомфорта. И Оконный ГУЙ ("в стиле Виндоус") в данном случае выступает как раз в роли такого унифицированного средства. Но "интуитивной понятностью" здесь и не пахло.

P.S. А каламбур, э-э-э, дурацкий вышел. В стиле "я дартаньян, а вы все презервативы".

>А про CVS backend - мысль смешная, надо подумать:)

А смеятся тут нечего. Иногда админам и не такое приходится писать.
А если бы можно было писать backend'ы на перле - так вообще неплохо.

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

Не знаю, как у вас, но у меня слово "микро-софтинка" вызывает некоторые ассоциации ;)))

про noexec на /home

> noexec на ~?

Бл***, ну сколько раз можно повторять:

# mount -t tmpfs tmpfs /mnt -o rw,nosuid,noexec,nodev,mode=1777

$ cp /bin/ls /mnt

$ /mnt/ls

bash: /mnt/ls: Permission denied

$ /lib/ld-linux.so.2 /mnt/ls

articles build deb disser src tmp work

P.S. Задолбали, честное слово, уже раз 50 этот пример показывал.

еще про noexec

> > В Mozille назначить этот самый startMyHackerXprog.sh MIME helper'-ом.

> noexec на ~? Мы вообще про песочницу говорим, или где?

/bin/bash -c "source startMyHackerXprog.sh"

плохо, коль пироги печет сапожник...

> Скажем так, для меня еще может быть вопрос в том, возможно или нет.

Невозможно.

> То, что на уровне десктопа это эффективно - я убежден.

Это прото НЕ работает. И не будет работать. Если ОС не запрещает что-то сделать, то это _можно_ сделать.

> Потому что на уровне десктопа полиси формулируется именно в терминах десктопа, а не в терминах каких-то функций

Кто Вам мешает написать макросы для того, чтоб сформулировать policy как-там-Вы-хотите?

> какого дьявола админ должен знать имена функций, которые входят в xlib API

А какого дьявола админ должен знать кучу ключей gconf? xlib API -- оно одно для всех, а у каждой софтины куча специфичных для нее ключей...

> или файлов (при чем тут файлы, если я хочу запретить смену скринейвера?).

Everything is file, and even if it is not, it MUST be :)

Тут опять вспоминается plan9...

А в чем заключается ваша работа как программиста? Обязателен ли Вам доступ к шеллу?

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

> То есть, так и запишем: в текущем своем состоянии gconf для этого непригоден. Вечно перспективный, блин.

Ну да. Только при этом запишите в скобках, что XML формат очень даже хорош для таких вещей - независимо от недоработок в gconf.

> Нет, слава Богу, для этого есть и более здравые решения.

А если я именно хочу в гуевой тулзе видеть эти комментарии - поскольку они имеют смысл. Да и чтобы конфигурялка понимал их смысл - что это changelog? Придется Вам вводить специальные теги в комментариях (типа javadoc). И что - в результате у Вас получится формат не сильно проще XML.

> А если не работала? А опыт работы с компьютерами в бытность её глав.бухом областного вторчермета, - он считается за опыт? :-) И,

Разумеется, считается.

> потом, откуда эти "периодические" цензы взяты, про год? Это где-нибудь в GNOME HIG написано, или Вы сами из головы это сейчас выдумали? Изначально, напомню, речь шла об "интуитивной понятности", т.е. "интуиция" - единственное и достаточное условие для "понятности", нет?

Из головы сейчас выдумал. Как и Вы пример с бабушкой:) Интуиция ИМХО воспитывается. И зависит от опыта. Лично я (не GNOME, не HIG - типическое ИМХО) под интуитивно-понятным понимаю интерфейс, понятный человеку с неким опытом работы с компутером. И это мое определение согласуется с Вашей идеей об унифицированном интерфейсе.

> А каламбур, э-э-э, дурацкий вышел.

Ну, извините, я не специально:)

Вообще, к gconf есть перловый binding. Но вот идея сделать spi на перле - это интересно и ново (я не слыхал). Предложите в виде баги - может, народу понравится.

> Если ОС не запрещает что-то сделать, то это _можно_ сделать.

Я что-то запамятовал - Вы согласились, права в микроядерной ОС проверяет НЕ ОС, а пользовательский код? И я опять же забыл - какие Вы нашли отличия у сервиса файловой системы, проверяющего доступ к файлам - и gconfd, проверяющего доступ к ключам?

> Кто Вам мешает написать макросы для того, чтоб сформулировать policy как-там-Вы-хотите?

Никто не мешает. А Вы потом как по машинам это будете распространять - через rsync/mount - или все-таки в LDAP положите? Это вообще вторичный вопрос. Важно, не как (макросы там или что еще - при наличие gconftool я смогу макросам задавать генерацию скриптов для gconf) - а для кого. Вы хотите для SELinux. А мне вполне достаточно gconf. Да, еще вопрос - для задания правил SELinux обязательно быть рутом на машине?

> А какого дьявола админ должен знать кучу ключей gconf? xlib API -- оно одно для всех, а у каждой софтины куча специфичных для нее ключей...

Не должен. Я уже сказал - речь идет о пространстве имен пермишенов, а не о пространстве имен ключей gconf (мне кажется, первое по размеру должно быть сильно меньше). И оба эти пространства имен прекрасно ложатся в какое-то визуально отобразимое дерево (для gconf именно это дерево показывается в гуевом редакторе).

> Everything is file, and even if it is not, it MUST be :)

Но мы же знаем, что в унихе это не так. И вообще, я уже раньше сказал, что файлы и каталоги не нужны - нужен storage именованных объектов:)

> Увы и ах. "О дивный новый мир" (C) Олдос Хаксли, в действии - советую к прочтению. Кстати, с каких это пор *NIX стал поп-ОС ?

Спасибо за совет, дойдут руки до Хаксли - почитаю. А за что линух борется последние лет 5 - как не за то, чтобы стать поп-ОС?

> Незачто. Вообще - шикарный WM. Только, plz, без holy wars. ;-)

Я, не очень частно в них вступаю. И уж WM - явно не тот повод. У меня другие красные тряпки:)

> А в чем заключается ваша работа как программиста? Обязателен ли Вам доступ к шеллу?

Обязателен. и не только к шеллу :-) Да, согласно вашей терминологии я разработчик.

> Очень может быть, в случае разработчика действительно только административно-командное решение может что-то ограничить. Особенно с учетом того, что у Вас есть физический доступ к машине.

Абсолютно логично. И без физического доступа к машине, смею заверить, тоже. Лишь бы на ней был account.

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

Речь идёт о нормальном рабочем процессе, и функциональности, какая для этого процесса мне нужна.

И чем разнообразнее круг решаемых задач, или шире набор требуемого инструметария, или посто требуется один-два-три, но сложных инструмента (xemacs + C compiler + shell, например :-) -- и загнать человека в какие-то рамки _только_ техническими средствами становится невозможно. Гораздо эффективнее становится людей просто учить + прививать принятую в данной конторе корпоративную культуру. И, по моему, это гораздо более эффективный путь. Особенно, если задумываться о будущем.

> Но для менеджеров-секретарш задача решаема на уровне десктопа.

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

> А за что линух борется последние лет 5 - как не за то, чтобы стать поп-ОС?

А почему "массовый" обязательно "поп" ? Умных людей мало ? Идиотам хватит и MS. Не вижу смысла развивать что-то только за ради того что отобрать юзверей у кого-то - что, оригинальные идеи кончились ? Стоило ли развивать Linux чтобы потом прийти к Windows в её худшей реинкарнации.

>Вообще, к gconf есть перловый binding. Но вот идея сделать spi на перле -
>это интересно и ново (я не слыхал). Предложите в виде баги - может,
>народу понравится.

Извините - не совсем понял - чем binding отличается от spi ?

> А микроядро - знает что-то про "можно позволить"?

Да. См., например Mach port rights.

> Оно просто передает какую-то мессагу - а смысл ее для ядра темен.

Если посылающий поток имеет право ее отправить принимающему, а принимающий поток имеет право принять ее у посылающего (из первого не следует второе, и обратно).

> Так чем же оно отличается от линуха, который передает пакетики для gconfd?

Тем, что оно спрашивает у auth-server'-а, можно ли посылать это сообщение.

> Допустим, в случае с микроядром у меня есть сервис файловой системы. И он обслуживает некий диск. На нем файл с правами 555. Кто не даст записать этот файл - ОС или сервис файловой системы?

Сервер ФС ничего про права не знает.

Поток хочет записать что-то в файл и делает IPC к серверу ФС, ядро спрашивает у auth сервера, следует ли разрешить такой IPC. auth-server примет решение (исходя из ACL, security policy, еще чего-то), что нельзя. Ядро не разрешит делать IPC и пошлет уведомление потоку, который его попытался сделать. Все, _никаким_ способом в этот файл Вы не запишете -- любой [IR]PC идет через ядро с одобрения auth'-сервера.

> ??? Это мрачно. А как-то крупноблочно это можно оформить?

Дык для того там m4 и используется.

> И - главное - Вы сместили акцент на конкретные функции X для конкретного окна.

Хотели fine-grained security -- ее и получили.

>А кто сказал, что я не захочу в root запустить какой-нибудь xsnow - он же не скринсейвер?

Все, что не разрешено -- запрещено. Поэтому нужно будет либо пометить xsnow как screensaver_exec_t, либо дать нужные права еще каким-нибудь доменам.