[devel] alternatives

[devel] alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

Доброго времени суток.

Сегодня стал знакомиться с alternatives.
Брови полезли наверх почти сразу.

>    <group name="candidate">
>        <option name="link" type="string"  value="/usr/bin/gcc" />
>        <option name="real" type="string" value="/usr/bin/colorifer" />
>        <option name="weight" type="number" value="50" />

Спецификация XML (есть DTD? Schema?) для описания кандидатов
чересчур громоздка. Зачем все эти <group name="candidate"/>
и <option name="link" type="string" value="..."/>, когда достаточно:
<candidate/> и <link file="..."/>

>    1. Из-за особенностей кодирования путей к файлам в именах
>       кадидатов запрещается использование
>    символа '|'

Чем изобретать схемы кодирования путей и запрещать символы,
не лучше ли отобразить иерархию на каталог, где размещаются ссылки?
И каталог будет выглядеть аккуратно, и в bash эти ссылки
можно будет набирать, пользуясь автодополнением (попробуйте,
какой гемор доставляют сейчас "особенности кодирования").
Сейчас ссылки мешаются с каталогами auto, manual, старыми
альтернативами и пр. Наверное, лучше спрятать их под
/etc/alternatives/links, и сделать реальными именами путей,
повторяющими файловую систему от корня.

Неясно, зачем было завязывать эти маленькие утилиты на C++,
ставя работоспособность системы в зависимость от колебаний
C++ ABI. Конечно, у всех разработчиков свои предпочтения,
а иметь библиотеку имени себя в дистрибутиве -- вообще шик. ;)
Но то, что я вижу в libing, можно было не напрягаясь
сделать в C, призвав на подмогу glib2 и libxml2.
Там, где не нужны классовые иерархии, C++ есть стрельба
из пушки по воробьям. Вдобавок, если и дальше пользоваться
расхожими метафорами, из этой же пушки легко прострелить
себе ногу.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Hodie natus est radici frater.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] alternatives, security issues of

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

Hello devel,

Некоторые мысли вслед.

On Sat, Mar 29, 2003 at 04:11:57PM +0300, Mikhail Zabaluev wrote:
>
> >    1. Из-за особенностей кодирования путей к файлам в именах
> >       кадидатов запрещается использование
> >    символа '|'
> 
> Чем изобретать схемы кодирования путей и запрещать символы,
> не лучше ли отобразить иерархию на каталог, где размещаются ссылки?
> И каталог будет выглядеть аккуратно, и в bash эти ссылки
> можно будет набирать, пользуясь автодополнением (попробуйте,
> какой гемор доставляют сейчас "особенности кодирования").
> Сейчас ссылки мешаются с каталогами auto, manual, старыми
> альтернативами и пр. Наверное, лучше спрятать их под
> /etc/alternatives/links, и сделать реальными именами путей,
> повторяющими файловую систему от корня.

У существующей схемы есть ещё и недостаток с точки зрения
безопасности: в /etc/alternatives видны все линки, тогда
как некоторые из sources и targets могут быть в скрытых
каталогах. Если вместе со структурой каталогов
копировать в /etc/alternatives/links и права на них, 
сокрытие не будет нарушено.

Вообще имеется вопрос, зачем пропускать ссылки через
промежуточную стадию в /etc/alternatives? Оно, конечно,
сразу даёт пользователю понять, что тут не всё просто
и просто перекидывать ссылки не рекомендуется.
Но если вся конфигурация записана в XML-файлах,
что мешает ссылаться прямо на target, при возможности
восстановить порушенные ссылки в случае необходимости?

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Knowledge is power -- knowledge shared is power lost.
		-- Aleister Crowley

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] alternatives, security issues of

[Ivan Zakharyaschev]

	Hello, Mikhail!

On Sat, 29 Mar 2003, Mikhail Zabaluev wrote:

> Вообще имеется вопрос, зачем пропускать ссылки через
> промежуточную стадию в /etc/alternatives? Оно, конечно,

Это вроде объяснялось ещё в старых alternatives: так изменение
варианта не требует изменений нигде в файловой системе, кроме
/etc -- как и положено для действия по конфигурированию системы.
Например, /usr (и /usr/bin) может быть на несколько систем один
(и смонтирован ro), а альтернативы выбраны по-разному.

> сразу даёт пользователю понять, что тут не всё просто
> и просто перекидывать ссылки не рекомендуется.
> Но если вся конфигурация записана в XML-файлах,
> что мешает ссылаться прямо на target, при возможности
> восстановить порушенные ссылки в случае необходимости?

-- 
С наилучшими пожеланиями,
Иван Захарьящев, Москва

JID: imz at altlinux.org

Re: [devel] alternatives

[Alexander Bokovoy]

On Sat, Mar 29, 2003 at 04:11:57PM +0300, Mikhail Zabaluev wrote:
> >    <group name="candidate">
> >        <option name="link" type="string"  value="/usr/bin/gcc" />
> >        <option name="real" type="string" value="/usr/bin/colorifer" />
> >        <option name="weight" type="number" value="50" />
> 
> Спецификация XML (есть DTD? Schema?) для описания кандидатов
> чересчур громоздка. Зачем все эти <group name="candidate"/>
> и <option name="link" type="string" value="..."/>, когда достаточно:
> <candidate/> и <link file="..."/>
Поддерживаю. Не надо плодить слишком формализованный синтаксис для решения
вообщем-то достаточно простой задачи.

> 
> >    1. Из-за особенностей кодирования путей к файлам в именах
> >       кадидатов запрещается использование
> >    символа '|'
> 
> Чем изобретать схемы кодирования путей и запрещать символы,
> не лучше ли отобразить иерархию на каталог, где размещаются ссылки?
> И каталог будет выглядеть аккуратно, и в bash эти ссылки
> можно будет набирать, пользуясь автодополнением (попробуйте,
> какой гемор доставляют сейчас "особенности кодирования").
> Сейчас ссылки мешаются с каталогами auto, manual, старыми
> альтернативами и пр. Наверное, лучше спрятать их под
> /etc/alternatives/links, и сделать реальными именами путей,
> повторяющими файловую систему от корня.
Здравая идея.


> Неясно, зачем было завязывать эти маленькие утилиты на C++,
> ставя работоспособность системы в зависимость от колебаний
> C++ ABI. Конечно, у всех разработчиков свои предпочтения,
> а иметь библиотеку имени себя в дистрибутиве -- вообще шик. ;)
> Но то, что я вижу в libing, можно было не напрягаясь
> сделать в C, призвав на подмогу glib2 и libxml2.
> Там, где не нужны классовые иерархии, C++ есть стрельба
> из пушки по воробьям. Вдобавок, если и дальше пользоваться
> расхожими метафорами, из этой же пушки легко прострелить
> себе ногу.
Не будем стреляться, но все же и мне кажется, что использование в данном
случае C++ не обосновано реальными требованиями.


-- 
/ Alexander Bokovoy
---
Oh, give me a home,
Where the buffalo roam,
And I'll show you a house with a really messy kitchen.

Re: [devel] alternatives, security issues of

[Alexey Voinov]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

Mikhail Zabaluev wrote
> Вообще имеется вопрос, зачем пропускать ссылки через
> промежуточную стадию в /etc/alternatives? Оно, конечно,
> сразу даёт пользователю понять, что тут не всё просто
> и просто перекидывать ссылки не рекомендуется.
> Но если вся конфигурация записана в XML-файлах,
> что мешает ссылаться прямо на target, при возможности
> восстановить порушенные ссылки в случае необходимости?
Предположим, что /usr смонтирована в readonly...

-- 
Best Regards!           | Когда вам платят за работу, надо по крайней мере
Alexey Voinov           | делать вид, что вы работаете...
                        |                         Б.Виан "Осень в Пекине"
voins@voins.program.ru
vns@altlinux.ru


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] alternatives

[Alexey Voinov]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

Mikhail Zabaluev wrote
> Доброго времени суток.
> 
> Сегодня стал знакомиться с alternatives.
> Брови полезли наверх почти сразу.
> >    <group name="candidate">
> >        <option name="link" type="string"  value="/usr/bin/gcc" />
> >        <option name="real" type="string" value="/usr/bin/colorifer" />
> >        <option name="weight" type="number" value="50" />
> Спецификация XML (есть DTD? Schema?) для описания кандидатов
> чересчур громоздка. Зачем все эти <group name="candidate"/>
> и <option name="link" type="string" value="..."/>, когда достаточно:
> <candidate/> и <link file="..."/>
Я бы сказал, что над этим ведётся работа. :) Если есть конкретные
предложения, думаю никто не будет против, если они буду здесь высказаны.

> Неясно, зачем было завязывать эти маленькие утилиты на C++,
> ставя работоспособность системы в зависимость от колебаний
> C++ ABI. Конечно, у всех разработчиков свои предпочтения,
> а иметь библиотеку имени себя в дистрибутиве -- вообще шик. ;)
> Но то, что я вижу в libing, можно было не напрягаясь
> сделать в C, призвав на подмогу glib2 и libxml2.
> Там, где не нужны классовые иерархии, C++ есть стрельба
> из пушки по воробьям. Вдобавок, если и дальше пользоваться
> расхожими метафорами, из этой же пушки легко прострелить
> себе ногу.
Как бы это помягче сказать....
Я правильно понял, что предложение заключается в замене libstdc++ (716578)
на glib2 (1207356) и переходе на менее удобный (для того, кто это пишет)
синтаксис? :)

В чём преимущество предложенного?

-- 
Best Regards!           | Когда вам платят за работу, надо по крайней мере
Alexey Voinov           | делать вид, что вы работаете...
                        |                         Б.Виан "Осень в Пекине"
voins@voins.program.ru
vns@altlinux.ru


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

Hello Alexey,

On Sat, Mar 29, 2003 at 10:41:29PM +0300, Alexey Voinov wrote:
>
> > Спецификация XML (есть DTD? Schema?) для описания кандидатов
> > чересчур громоздка. Зачем все эти <group name="candidate"/>
> > и <option name="link" type="string" value="..."/>, когда достаточно:
> > <candidate/> и <link file="..."/>
> Я бы сказал, что над этим ведётся работа. :) Если есть конкретные
> предложения, думаю никто не будет против, если они буду здесь высказаны.

Если взять пример, приведённый в README.RUS, и переработать:

<?xml version="1.0"?>
<link name="/usr/bin/gcc"
      target="/usr/bin/colorifer"
      priority="50">
  <slave name="/usr/bin/g++" target="/usr/bin/colorifer" />
  <slave name="/usr/bin/gcj" target="/usr/bin/colorifer" />
</link>


> Я правильно понял, что предложение заключается в замене libstdc++ (716578)
> на glib2 (1207356) и

Нужно учесть ещё накладные расходы на порождение кода из шаблонов.
std::map<foo, bar> вряд ли даётся бесплатно.

> переходе на менее удобный (для того, кто это пишет)
> синтаксис? :)

Более удобно -- это там, где опасным и неинтуитивным образом
переопределяются операторы непонятно для чего? ;)

> В чём преимущество предложенного?

В том, что не надо думать, каким компилятором собраны
библиотека и приложение. У нас сейчас полно головной
боли из-за gcc 2.96 и gcc 3.2. А если кто-нибудь,
не дай бог, захочет использовать компилятор Intel?
Стандартный ABI уже есть, но он молод и недостаточно
отлажен, не говоря уж о реализациях.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Remember -- only 10% of anything can be in the top 10%.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives, security issues of

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Hello Ivan,

On Sat, Mar 29, 2003 at 07:46:31PM +0300, Ivan Zakharyaschev wrote:
>
> > Вообще имеется вопрос, зачем пропускать ссылки через
> > промежуточную стадию в /etc/alternatives? Оно, конечно,
> 
> Это вроде объяснялось ещё в старых alternatives: так изменение
> варианта не требует изменений нигде в файловой системе, кроме
> /etc -- как и положено для действия по конфигурированию системы.

Если ссылки не существовало, изменить файловую систему всё-таки
придётся. Но в целом...

> Например, /usr (и /usr/bin) может быть на несколько систем один
> (и смонтирован ro), а альтернативы выбраны по-разному.

... я понял (не в первый раз). Спасибо.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
The world really isn't any worse.  It's just that the news coverage
is so much better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: alternatives

[Alexey Voinov]

[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]

Mikhail Zabaluev wrote
> > > Спецификация XML (есть DTD? Schema?) для описания кандидатов
> > > чересчур громоздка. Зачем все эти <group name="candidate"/>
> > > и <option name="link" type="string" value="..."/>, когда достаточно:
> > > <candidate/> и <link file="..."/>
> > Я бы сказал, что над этим ведётся работа. :) Если есть конкретные
> > предложения, думаю никто не будет против, если они буду здесь высказаны.
> Если взять пример, приведённый в README.RUS, и переработать:
> 
> <?xml version="1.0"?>
> <link name="/usr/bin/gcc"
>       target="/usr/bin/colorifer"
>       priority="50">
>   <slave name="/usr/bin/g++" target="/usr/bin/colorifer" />
>   <slave name="/usr/bin/gcj" target="/usr/bin/colorifer" />
> </link>

> > Я правильно понял, что предложение заключается в замене libstdc++ (716578)
> > на glib2 (1207356) и
> Нужно учесть ещё накладные расходы на порождение кода из шаблонов.
> std::map<foo, bar> вряд ли даётся бесплатно.
Всё решается во время компиляции.

Пример простого шаблона:
template <int i>
	struct f { static const int r = i * f<i-1>::r; };

template <>
	struct f<0> { static const int r = 1; };

Так вот, f<5>::r при компиляции заменяется костантой 120, а
f<10>::r --- 3628800. Где накладные расходы от шаблонов?
Я не вижу.


> > переходе на менее удобный (для того, кто это пишет)
> > синтаксис? :)
> Более удобно -- это там, где опасным и неинтуитивным образом
> переопределяются операторы непонятно для чего? ;)
Конкретный пример можно? Оператор [] у std::map переопределён
неинтуитивно?

> > В чём преимущество предложенного?
> В том, что не надо думать, каким компилятором собраны
> библиотека и приложение. У нас сейчас полно головной
> боли из-за gcc 2.96 и gcc 3.2. А если кто-нибудь,
> не дай бог, захочет использовать компилятор Intel?
> Стандартный ABI уже есть, но он молод и недостаточно
> отлажен, не говоря уж о реализациях.
Не надо думать. У нас стандартный компилятор gcc3.2.
Исходники alternatives досупны, так что перекомпилировать можно
без проблем в любой момент.

Я скажу так: я начал делать свой вариант альтернатив на C (и без glib2),
но потом решил, что продуктивнее будет слать патчи к тому, что уже есть.
Постепенно это можно довести до очень неплохого состояния.

-- 
Best Regards!           | Когда вам платят за работу, надо по крайней мере
Alexey Voinov           | делать вид, что вы работаете...
                        |                         Б.Виан "Осень в Пекине"
voins@voins.program.ru
vns@altlinux.ru


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

Hello Alexey,

On Sun, Mar 30, 2003 at 11:44:31AM +0400, Alexey Voinov wrote:
>
> > > на glib2 (1207356) и

Без GObject и пр. имеем:

-rwxr-xr-x    1 root     root       435172 Фев  5 07:42 /usr/lib/libglib-2.0.so.0.200.1

Сам пакет большой, но в runtime это довольно компактная библиотека.

> > Нужно учесть ещё накладные расходы на порождение кода из шаблонов.
> > std::map<foo, bar> вряд ли даётся бесплатно.
> Всё решается во время компиляции.
> 
> Пример простого шаблона:
> template <int i>
> 	struct f { static const int r = i * f<i-1>::r; };
> 
> template <>
> 	struct f<0> { static const int r = 1; };
> 
> Так вот, f<5>::r при компиляции заменяется костантой 120, а
> f<10>::r --- 3628800. Где накладные расходы от шаблонов?
> Я не вижу.

Я говорил об std::map и других не вполне тривиальных классах.

> > > переходе на менее удобный (для того, кто это пишет)
> > > синтаксис? :)
> > Более удобно -- это там, где опасным и неинтуитивным образом
> > переопределяются операторы непонятно для чего? ;)
> Конкретный пример можно? Оператор [] у std::map переопределён
> неинтуитивно?

Класс Ing::FileSystem переопределяет * и ++ явно в целях
конспирации. Правильный operator++ должен возвращать отнюдь не bool.
Кстати, если уж переопределять ++, принято ещё и постфиксную форму
предоставлять.
Непонятно, почему вообще немудрёный итератор
по файловым деревьям назван FileSystem.
И почему у него семантика линейного итератора. Мне известны
как минимум два способа обхода дерева, см параметры утилиты
file. Файловые ссылки добавляют неопределённости.
Негибкий этот класс и в других отношениях: всегда делает fstat,
нужно это или нет (тем более что fts_* вроде бы предоставляют
и эти данные). В-общем, я не увидел здесь _полезного_
использования C++.

> > > В чём преимущество предложенного?
> > В том, что не надо думать, каким компилятором собраны
> > библиотека и приложение. У нас сейчас полно головной
> > боли из-за gcc 2.96 и gcc 3.2. А если кто-нибудь,
> > не дай бог, захочет использовать компилятор Intel?
> > Стандартный ABI уже есть, но он молод и недостаточно
> > отлажен, не говоря уж о реализациях.
> Не надо думать. У нас стандартный компилятор gcc3.2.

Разработчики GCC пока не дали гарантии, что C++ ABI версии 3.2
окончательный.

> Я скажу так: я начал делать свой вариант альтернатив на C (и без glib2),
> но потом решил, что продуктивнее будет слать патчи к тому, что уже есть.
> Постепенно это можно довести до очень неплохого состояния.

Да, вероятно.
Можно было бы постепенно сводить классы к их заменам на C.
В отсутствие наследования это будет нетрудно.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Sinners can repent, but stupid is forever.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] alternatives

[Igor Tertishny]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 564 bytes --]

29 Март 2003 13:11, Mikhail Zabaluev написал:
> Доброго времени суток.
>
> Сегодня стал знакомиться с alternatives.
> Брови полезли наверх почти сразу.
>

Я тоже несколько часов пытался разобраться в новых alternatives настроить 
простейшую вещь - замену automake, autocong, без чего не работает kdevelop. 
Ничего не смог сделать. информации никакой нет. man и info alternatives 
ничего не дают. Прошу подсказать где найти хоть какую инфу по их настройке, 
по добавлению новых альтернатив, вообще по работе с ними. Нужно срочно, 
работа стоит. Заранее благодарен.

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Hello Igor,

On Sun, Mar 30, 2003 at 08:01:40PM +0000, Igor Tertishny wrote:
>
> Я тоже несколько часов пытался разобраться в новых alternatives настроить 
> простейшую вещь - замену automake, autocong, без чего не работает kdevelop. 

?? Вам нужно определённые версии выставить? Это в ALT Linux нынче делается
через переменные окружения.

> Ничего не смог сделать. информации никакой нет. man и info alternatives 
> ничего не дают. Прошу подсказать где найти хоть какую инфу по их настройке, 
> по добавлению новых альтернатив, вообще по работе с ними. Нужно срочно, 
> работа стоит. Заранее благодарен.

Hint: man 8 update-alternatives

Это не очень прогрессивное средство будет работать ещё какое-то время. 

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
People humiliating a salami!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: alternatives

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Mon, Mar 31, 2003 at 12:20:22AM +0400, Mikhail Zabaluev wrote:
> On Sun, Mar 30, 2003 at 08:01:40PM +0000, Igor Tertishny wrote:
> >
> > Я тоже несколько часов пытался разобраться в новых alternatives настроить 
> > простейшую вещь - замену automake, autocong, без чего не работает kdevelop. 
> 
> ?? Вам нужно определённые версии выставить? Это в ALT Linux нынче делается
> через переменные окружения.

Для automake - через альтернативу /usr/bin/automake-default, которая
используется в случае, если переменная AUTOMAKE_VERSION не определена.
Аналогично с autoconf.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] alternatives

[Stanislav Ievlev]

Ну обо всём по порядку.
On Sat, Mar 29, 2003 at 04:11:57PM +0300, Mikhail Zabaluev wrote:
> Доброго времени суток.
> 
> Сегодня стал знакомиться с alternatives.
> Брови полезли наверх почти сразу.
Согласен, всё достаточно необычно сделано ;)
> 
> >    <group name="candidate">
> >        <option name="link" type="string"  value="/usr/bin/gcc" />
> >        <option name="real" type="string" value="/usr/bin/colorifer" />
> >        <option name="weight" type="number" value="50" />
> 
> Спецификация XML (есть DTD? Schema?)
Будут ;)
>для описания кандидатов
> чересчур громоздка. Зачем все эти <group name="candidate"/>
> и <option name="link" type="string" value="..."/>, когда достаточно:
> <candidate/> и <link file="..."/>
Эта громоздкость позволяет иметь общий формат конфигурационных файлов для разных
программ. При переходе на собственный конфигуратор это позволит облегчить
написание backend к нему.
> 
> >    1. Из-за особенностей кодирования путей к файлам в именах
> >       кадидатов запрещается использование
> >    символа '|'
> 
> Чем изобретать схемы кодирования путей и запрещать символы,
> не лучше ли отобразить иерархию на каталог, где размещаются ссылки?
> И каталог будет выглядеть аккуратно, и в bash эти ссылки
> можно будет набирать, пользуясь автодополнением (попробуйте,
> какой гемор доставляют сейчас "особенности кодирования").
> Сейчас ссылки мешаются с каталогами auto, manual, старыми
> альтернативами и пр. Наверное, лучше спрятать их под
> /etc/alternatives/links, и сделать реальными именами путей,
> повторяющими файловую систему от корня.
Был и такой вариант. Но преимуществ он никаких не несет, короме другого
размещения. А что делать если и каталог и файлы лежащие в нём будут оба
альтернативами?  Зачем использовать автодополнение для служебных ссылок?
Этот каталог можно считать чёрным ящиком и внутреннее его содержимое не
должно беспокоить пользователя.
> 
> Неясно, зачем было завязывать эти маленькие утилиты на C++,
> ставя работоспособность системы в зависимость от колебаний
> C++ ABI. Конечно, у всех разработчиков свои предпочтения,
> а иметь библиотеку имени себя в дистрибутиве -- вообще шик. ;)
Никак не мог придумать название ;)
> Но то, что я вижу в libing, можно было не напрягаясь
> сделать в C, призвав на подмогу glib2 и libxml2.
Не напрягаясь это можно сделать на многих средствах ... так что дискуссия
по этому поводу вряд ли будет конструктивной.
> Там, где не нужны классовые иерархии, C++ есть стрельба
> из пушки по воробьям. Вдобавок, если и дальше пользоваться
> расхожими метафорами, из этой же пушки легко прострелить
> себе ногу.
Ух. Если уж пользоваться метафорами, то "убить можно и простой авторучкой".
> 
> -- 
> Stay tuned,
>   MhZ                                     JID: mhz@altlinux.org
> ___________
> Hodie natus est radici frater.

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

Hello Stanislav,

On Mon, Mar 31, 2003 at 11:29:27AM +0400, Stanislav Ievlev wrote:
>
> > >    <group name="candidate">
> > >        <option name="link" type="string"  value="/usr/bin/gcc" />
> > >        <option name="real" type="string" value="/usr/bin/colorifer" />
> > >        <option name="weight" type="number" value="50" />
> > 
> > Спецификация XML (есть DTD? Schema?)
> Будут ;)
> >для описания кандидатов
> > чересчур громоздка. Зачем все эти <group name="candidate"/>
> > и <option name="link" type="string" value="..."/>, когда достаточно:
> > <candidate/> и <link file="..."/>
> Эта громоздкость позволяет иметь общий формат конфигурационных файлов для разных
> программ. При переходе на собственный конфигуратор это позволит облегчить
> написание backend к нему.

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

> > >    1. Из-за особенностей кодирования путей к файлам в именах
> > >       кадидатов запрещается использование
> > >    символа '|'
> > 
> > Чем изобретать схемы кодирования путей и запрещать символы,
> > не лучше ли отобразить иерархию на каталог, где размещаются ссылки?
> > И каталог будет выглядеть аккуратно, и в bash эти ссылки
> > можно будет набирать, пользуясь автодополнением (попробуйте,
> > какой гемор доставляют сейчас "особенности кодирования").
> > Сейчас ссылки мешаются с каталогами auto, manual, старыми
> > альтернативами и пр. Наверное, лучше спрятать их под
> > /etc/alternatives/links, и сделать реальными именами путей,
> > повторяющими файловую систему от корня.
> Был и такой вариант. Но преимуществ он никаких не несет, короме другого
> размещения.

В другом письме я говорил о проблеме безопасности: все ссылки видны.

> А что делать если и каталог и файлы лежащие в нём будут оба
> альтернативами?

Это безумие не будет надёжно работать при любой организации,
если не отслеживать префиксные отношения различных ссылок.
Я считаю, это должно быть явно запрещено: более чем
одномерные системы альтернатив вряд ли встретятся
на практике.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Harrison's Postulate:
	For every action, there is an equal and opposite criticism.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: alternatives

[Stanislav Ievlev]

Привет!

On Tue, Apr 01, 2003 at 03:09:43AM +0400, Mikhail Zabaluev wrote:
> > программ. При переходе на собственный конфигуратор это позволит облегчить
> > написание backend к нему.
> 
> Не стоит ради упрощения одного инструмента создавать проблемы всем
> разработчикам, которым эти файлы предстоит писать.
> Если так уж необходимо приведение к общему формату, можно гонять
> туда-обратно при помощи XSLT.
Я уже думал и про это. Во-первых формат не слишком сложен чтобы
разработчикам его использовать (это конечно же субъективно, сделай
короткий вариант, найдется кто-нибудь кому и это будет неудобно, xml сам
по себе достаточно громоздок), да и не надо его использовать каждый день. 
Во-вторых, я конечно же думал сделать специализированные 
форматы с перегонкой на общий через XSLT, но не могу
никак себя убедить что проще иметь десяток разных обработчиков +
транслятор, чем изначально один обработчик . Я
предпочитаю наблюдать все баги в одном месте, а не десяти.

... Тем не менее любую помощь и предложения по формату принимаю. Я не
хотел бы спешить и быстро сейчас всё перекручивать. Всё подлежит
длительному обдумыванию. Именно поэтому новая версия сделана чтобы жить
совместно со старой ;)
> 
> > > >    1. Из-за особенностей кодирования путей к файлам в именах
> > > >       кадидатов запрещается использование
> > > >    символа '|'
> > > 
> > > Чем изобретать схемы кодирования путей и запрещать символы,
> > > не лучше ли отобразить иерархию на каталог, где размещаются ссылки?
> > > И каталог будет выглядеть аккуратно, и в bash эти ссылки
> > > можно будет набирать, пользуясь автодополнением (попробуйте,
> > > какой гемор доставляют сейчас "особенности кодирования").
> > > Сейчас ссылки мешаются с каталогами auto, manual, старыми
> > > альтернативами и пр. Наверное, лучше спрятать их под
> > > /etc/alternatives/links, и сделать реальными именами путей,
> > > повторяющими файловую систему от корня.
> > Был и такой вариант. Но преимуществ он никаких не несет, короме другого
> > размещения.
> 
> В другом письме я говорил о проблеме безопасности: все ссылки видны.
Ну и что, принадлежат ведь они руту. security by obsсurity?
Они и так и так будут видны как не крути ;)
> 
> > А что делать если и каталог и файлы лежащие в нём будут оба
> > альтернативами?
> 
> Это безумие не будет надёжно работать при любой организации,
Ну почему же, вот например сейчас уже работает vi. У которого есть
альтернатива vim-X11, которая в свою очередь тоже является альтернативой
;))
И это не моё изобретение ;)))
> если не отслеживать префиксные отношения различных ссылок.
> Я считаю, это должно быть явно запрещено: более чем
> одномерные системы альтернатив вряд ли встретятся
> на практике.
Ну а если они одномерные то тогда тем более не пойму зачем городить огород
из каталогов.
> 
> -- 
> Stay tuned,
>   MhZ                                     JID: mhz@altlinux.org
> ___________
> Harrison's Postulate:
> 	For every action, there is an equal and opposite criticism.

Re: [devel] Re: alternatives

[Stanislav Ievlev]

> > > > синтаксис? :)
> > > Более удобно -- это там, где опасным и неинтуитивным образом
> > > переопределяются операторы непонятно для чего? ;)
> > Конкретный пример можно? Оператор [] у std::map переопределён
> > неинтуитивно?
> 
> Класс Ing::FileSystem переопределяет * и ++ явно в целях
> конспирации. Правильный operator++ должен возвращать отнюдь не bool.
Ну это бабушка надвое сказала, нигде не определены жесткие правила перегрузки
опрераторов, другое дело, что это может быть общепринято.
> Кстати, если уж переопределять ++, принято ещё и постфиксную форму
> предоставлять.
> Непонятно, почему вообще немудрёный итератор
> по файловым деревьям назван FileSystem.
> И почему у него семантика линейного итератора. Мне известны
> как минимум два способа обхода дерева, см параметры утилиты
> file. Файловые ссылки добавляют неопределённости.
> Негибкий этот класс и в других отношениях: всегда делает fstat,
> нужно это или нет (тем более что fts_* вроде бы предоставляют
> и эти данные). В-общем, я не увидел здесь _полезного_
> использования C++.
fts-то конечно предоставляет fstat, но типичный TOCTOU race остается. Если Вы
внимательно посмотрели, то там вся фишка не столько в fstat, сколько в
open.

А вот мысль по поводу интерфейса мне показалась разумной. Наверное лучше
сделать его больше похожим на поток, так будет ближе к сути ... да и к fts
тоже. Михаил, как считаете?

--
С наилучшими пожеланиями
Станислав Иевлев.

[devel] no black box (was: alternatives)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Mon, Mar 31, 2003 at 11:29:27AM +0400, Stanislav Ievlev wrote:
> Зачем использовать автодополнение для служебных ссылок?

Затем, что это может быть удобно.

> Этот каталог можно считать чёрным ящиком и внутреннее его
> содержимое не должно беспокоить пользователя.

Нет!  Мне и так хватает того, что /boot и /lib/modules
замаскированы разрешениями.  За черноящичьем идет чернокнижие.

Т.е. лично _мне_ [ :) ] хотелось бы видеть дистрибутив остающимся
_прозрачным_ -- в конце концов, спросите support@, какую проблему
будет легче отлавливать -- ту, где на той стороне могут что-то
понять и рассказать сами, или ту, где придется ехать к этому
ящику с кайлом.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Mon, 31 Mar 2003 11:29:27 +0400
Stanislav Ievlev <inger@altlinux.org> wrote:

<skipped/>

> > >    <group name="candidate">
> > >        <option name="link" type="string" 
> > >        value="/usr/bin/gcc" /><option name="real"
> > >        type="string" value="/usr/bin/colorifer" /><option
> > >        name="weight" type="number" value="50" />
> > 
> > Спецификация XML (есть DTD? Schema?)
> Будут ;)

IMHO:
Очень жаль. Известны случаи, когда разработка велась по конфигу,
структура которого не была продумана и определена в DTD - jabber,
yank - получалось... не очень. А структура конфига влияет и на
саму программу.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]

Hello Stanislav,

On Tue, Apr 01, 2003 at 11:37:04AM +0400, Stanislav Ievlev wrote:
>
> > > > >    1. Из-за особенностей кодирования путей к файлам в именах
> > > > >       кадидатов запрещается использование
> > > > >    символа '|'
> > > > 
> > > > Чем изобретать схемы кодирования путей и запрещать символы,
> > > > не лучше ли отобразить иерархию на каталог, где размещаются ссылки?
> > > > И каталог будет выглядеть аккуратно, и в bash эти ссылки
> > > > можно будет набирать, пользуясь автодополнением (попробуйте,
> > > > какой гемор доставляют сейчас "особенности кодирования").
> > > > Сейчас ссылки мешаются с каталогами auto, manual, старыми
> > > > альтернативами и пр. Наверное, лучше спрятать их под
> > > > /etc/alternatives/links, и сделать реальными именами путей,
> > > > повторяющими файловую систему от корня.
> > > Был и такой вариант. Но преимуществ он никаких не несет, короме другого
> > > размещения.
> > 
> > В другом письме я говорил о проблеме безопасности: все ссылки видны.
> Ну и что, принадлежат ведь они руту. security by obsсurity?
> Они и так и так будут видны как не крути ;)

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

> > 
> > > А что делать если и каталог и файлы лежащие в нём будут оба
> > > альтернативами?
> > 
> > Это безумие не будет надёжно работать при любой организации,
> Ну почему же, вот например сейчас уже работает vi. У которого есть
> альтернатива vim-X11, которая в свою очередь тоже является альтернативой
> ;))

Насколько я понял, это одномерная цепочка ссылок и она вполне
реализуема предложенным мной образом.
Подумайте, как поддержать наличие альтернативы /foo/bar/baz, если
каталог /foo/bar сам является альтернативой и может переключаться
между различными вариантами. Эта конструкция будет расползаться
от неосторожного вздоха и доставлять всем головную боль,
пропорциональную произведению кратности одной альтернативы
на кратность другой :)

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

Суммирую по пунктам:
- отсутствие необходимости в кривых схемах кодирования;
- закрытость конфигурации ссылок такая же, как закрытость имён самих ссылок;
- более рациональное использование файловой системы.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
You will hear good news from one you thought unfriendly to you.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: alternatives

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

On Tue, Apr 01, 2003 at 04:14:30PM +0400, Mikhail Zabaluev wrote:
> - закрытость конфигурации ссылок такая же, как закрытость имён самих ссылок;

Неочевидно.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

Hello Dmitry,

On Tue, Apr 01, 2003 at 05:00:47PM +0400, Dmitry V. Levin wrote:
>
> On Tue, Apr 01, 2003 at 04:14:30PM +0400, Mikhail Zabaluev wrote:
> > - закрытость конфигурации ссылок такая же, как закрытость имён самих ссылок;
> 
> Неочевидно.

Если ставить права на каталоги в конфигурационном древе
такими же, как на их прообразы -- разве неочевидно?
Тогда давайте контрпример :)

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
A long memory is the most subversive idea in America.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1.1: Type: text/plain, Size: 1739 bytes --]

Hello Stanislav,

On Tue, Apr 01, 2003 at 11:37:04AM +0400, Stanislav Ievlev wrote:
>
> Привет!
> 
> On Tue, Apr 01, 2003 at 03:09:43AM +0400, Mikhail Zabaluev wrote:
> > > программ. При переходе на собственный конфигуратор это позволит облегчить
> > > написание backend к нему.
> > 
> > Не стоит ради упрощения одного инструмента создавать проблемы всем
> > разработчикам, которым эти файлы предстоит писать.
> > Если так уж необходимо приведение к общему формату, можно гонять
> > туда-обратно при помощи XSLT.
> Я уже думал и про это. Во-первых формат не слишком сложен чтобы
> разработчикам его использовать (это конечно же субъективно, сделай
> короткий вариант, найдется кто-нибудь кому и это будет неудобно, xml сам
> по себе достаточно громоздок), да и не надо его использовать каждый день. 
> Во-вторых, я конечно же думал сделать специализированные 
> форматы с перегонкой на общий через XSLT, но не могу
> никак себя убедить что проще иметь десяток разных обработчиков +
> транслятор, чем изначально один обработчик . Я
> предпочитаю наблюдать все баги в одном месте, а не десяти.

Я бы обратил логику: транслятор/обработчик пишется и отлаживается
один раз, а файлы создаются и редактируются постоянно. Где
будут чаще всего возникать ошибки?

К тому же, если всё-таки соберётесь делать schema,
замучаетесь с определением валидности каждого из приложений
общего формата. Со специализированным форматом это сделать
гораздо проще.

Короче, приложены два XSL-преобразования для перегонки
между обсуждаемыми форматами в обе стороны.
Надеюсь, это поможет продвинуться на Истинном Пути XML :)

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
filesystem not big enough for Jumbo Kernel Patch

[-- Attachment #1.2: alternatives-bloat.xsl --]
[-- Type: text/xml, Size: 1254 bytes --]

<?xml version="1.0"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	       version="1.0">

<!-- Transform alternatives file from the proposed brief format to 
     the "common" bloated configuration format -->

<xsl:output method="xml" indent="yes"/>

<xsl:template match="/link">
  <group name="candidate">
    <option name="link" type="string">
      <xsl:attribute name="value">
        <xsl:value-of select="@name"/>
      </xsl:attribute>
    </option>
    <option name="real" type="string">
      <xsl:attribute name="value">
        <xsl:value-of select="@target"/>
      </xsl:attribute>
    </option>
    <option name="weight" type="number">
      <xsl:attribute name="value">
        <xsl:value-of select="@priority"/>
      </xsl:attribute>
    </option>
    <xsl:apply-templates select="slave"/>
  </group>
</xsl:template>

<xsl:template match="slave">
  <group name="slave">
    <option name="link" type="string">
      <xsl:attribute name="value">
        <xsl:value-of select="@name"/>
      </xsl:attribute>
    </option>
    <option name="real" type="string">
      <xsl:attribute name="value">
        <xsl:value-of select="@target"/>
      </xsl:attribute>
    </option>
  </group>
</xsl:template>

</xsl:transform>

[-- Attachment #1.3: alternatives-debloat.xsl --]
[-- Type: text/xml, Size: 1080 bytes --]

<?xml version="1.0"?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	       version="1.0">

<!-- Transform alternatives file from the "common"
     bloated configuration format to the proposed brief format -->

<xsl:output method="xml" indent="yes"/>

<xsl:template match="/group[@name='candidate']">
  <link>
    <xsl:attribute name="name">
      <xsl:value-of select="option/@value[../@name='link']"/>
    </xsl:attribute>
    <xsl:attribute name="target">
      <xsl:value-of select="option/@value[../@name='real']"/>
    </xsl:attribute>
    <xsl:attribute name="priority">
      <xsl:value-of select="option/@value[../@name='weight']"/>
    </xsl:attribute>
    <xsl:apply-templates select="group"/>
  </link>
</xsl:template>

<xsl:template match="group[@name='slave']">
  <slave>
    <xsl:attribute name="name">
      <xsl:value-of select="option/@value[../@name='link']"/>
    </xsl:attribute>
    <xsl:attribute name="target">
      <xsl:value-of select="option/@value[../@name='real']"/>
    </xsl:attribute>
  </slave>
</xsl:template>

</xsl:transform>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: alternatives

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Tue, Apr 01, 2003 at 11:13:06PM +0400, Mikhail Zabaluev wrote:
> > > - закрытость конфигурации ссылок такая же, как закрытость имён самих ссылок;
> > 
> > Неочевидно.
> 
> Если ставить права на каталоги в конфигурационном древе
> такими же, как на их прообразы -- разве неочевидно?
> Тогда давайте контрпример :)

Какая разница с точки зрения obscurity, будет
$ readlink /usr/bin/automake-default
/etc/alternatives/|usr|bin|automake-default
или, скажем,
/etc/alternatives/usr/bin/automake-default
если сделать
# chmod -R go-r /etc/alternatives
?


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

Hello Dmitry,

On Tue, Apr 01, 2003 at 11:59:36PM +0400, Dmitry V. Levin wrote:
>
> On Tue, Apr 01, 2003 at 11:13:06PM +0400, Mikhail Zabaluev wrote:
> > > > - закрытость конфигурации ссылок такая же, как закрытость имён самих ссылок;
> > > 
> > > Неочевидно.
> > 
> > Если ставить права на каталоги в конфигурационном древе
> > такими же, как на их прообразы -- разве неочевидно?
> > Тогда давайте контрпример :)
> 
> Какая разница с точки зрения obscurity, будет
> $ readlink /usr/bin/automake-default
> /etc/alternatives/|usr|bin|automake-default
> или, скажем,
> /etc/alternatives/usr/bin/automake-default
> если сделать
> # chmod -R go-r /etc/alternatives
> ?

Поздравляю, вы закрыли всем доступ ко всем ссылкам.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
A rolling disk gathers no MOS.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

Hello ALT,

On Wed, Apr 02, 2003 at 12:16:28AM +0400, Mikhail Zabaluev wrote:
>
> > Какая разница с точки зрения obscurity, будет
> > $ readlink /usr/bin/automake-default
> > /etc/alternatives/|usr|bin|automake-default
> > или, скажем,
> > /etc/alternatives/usr/bin/automake-default
> > если сделать
> > # chmod -R go-r /etc/alternatives
> > ?
> 
> Поздравляю, вы закрыли всем доступ ко всем ссылкам.

Вру, если доступ будет 711, действительно будет то, что надо.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Blue paint today.
		[Funny to Jack Slingwine, Guy Harris and Hal Pierson.  Ed.]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: alternatives

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Wed, Apr 02, 2003 at 12:16:28AM +0400, Mikhail Zabaluev wrote:
> On Tue, Apr 01, 2003 at 11:59:36PM +0400, Dmitry V. Levin wrote:
> > On Tue, Apr 01, 2003 at 11:13:06PM +0400, Mikhail Zabaluev wrote:
> > > > > - закрытость конфигурации ссылок такая же, как закрытость имён самих ссылок;
> > > > 
> > > > Неочевидно.
> > > 
> > > Если ставить права на каталоги в конфигурационном древе
> > > такими же, как на их прообразы -- разве неочевидно?
> > > Тогда давайте контрпример :)
> > 
> > Какая разница с точки зрения obscurity, будет
> > $ readlink /usr/bin/automake-default
> > /etc/alternatives/|usr|bin|automake-default
> > или, скажем,
> > /etc/alternatives/usr/bin/automake-default
> > если сделать
> > # chmod -R go-r /etc/alternatives
> > ?
> 
> Поздравляю, вы закрыли всем доступ ко всем ссылкам.

Вы же именно этого хотели?
Работать - пожалуйста, смотреть - нет.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Sat, Mar 29, 2003 at 04:11:57PM +0300, Mikhail Zabaluev wrote:
> Спецификация XML (есть DTD? Schema?) для описания кандидатов
> чересчур громоздка.

Я могу показаться ренегатом, но по здравом размышлении у меня
появилось подозрение, что alternatives -- вообще достаточно
_базовое_ средство для того, чтобы не пытаться интегрировать его
с конфигуратором, "общим форматом конфигов" etc.

Например, можно "улучшить" /bin/bash до хранения *rc etc в XML,
но стоит ли?

"За" я вижу один довод -- модуль в конфигуратор, позволяющий
"поставить галочку" напротив (скажем) версии gcc.

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

PS: это все handwaving, а не code, поэтому может быть
проигнорировано.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: alternatives

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Tue, Apr 01, 2003 at 11:59:36PM +0400, Dmitry V. Levin wrote:
> Какая разница с точки зрения obscurity, будет
[snip]
> если сделать
> # chmod -R go-r /etc/alternatives
> ?

Такая, что последний метод является кувалдометрическим.

Вообще мне пока как-то смутно видятся преимущества
параноидального подхода к alternatives.  Разве что у нас
/usr/sbin/pop3d будет таким, но в это слабо верится по ряду
других причин, которые важнее, чем путь к конкретно используемому
бинарнику (например, аргументы и вообще стиль использования --
standalone vs wrapped).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]