[devel] Управление группами пользователя

[devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

Для нормальной работы пользователям в Linux необходимо являться членом
некоторых групп, например cdwriter, audio.

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

С помощью NSS модуля, разработанного нами, можно решить эту проблему
более красивым способом. Модуль находится по адресу
http://www.tartarus.ru/wiki/Projects/libnss_role и позволяет добавлять
группу в группы.

С его помощью можно создать группу users и добавить ее в необходимые
пользователям группы (audio, cdwriter, ...). Пользователей же
добавлять только в группу users, а в остальные они попадут
автоматически. Более того, группу администраторов можно ввести схожим
образом, а именно, создав группу admins, и добавив ее в группы users и
wheel.

Можно придумать и более интересные применения этого модуля. Может
стоит нам использовать его возможности по умолчанию? Соответственно
исправить альтератор для работы с ним.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Alexander Bokovoy]

2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> Можно придумать и более интересные применения этого модуля. Может
> стоит нам использовать его возможности по умолчанию? Соответственно
> исправить альтератор для работы с ним.
Суммируя, этот модуль делает поддержку nested groups, раскрывая их во
время исполнения.
Модуль написан на C++ и в любое приложение в системе тянет за собой
/usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).

Теперь главный вопрос: чем не устраивает поддержка RFC2307bis в
nss_ldap? Она существует с 2002 года и отлично работает.
-- 
/ Alexander Bokovoy

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 21:01 пользователь Alexander Bokovoy
<ab@altlinux.org> написал:
> 2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
>> Можно придумать и более интересные применения этого модуля. Может
>> стоит нам использовать его возможности по умолчанию? Соответственно
>> исправить альтератор для работы с ним.
> Суммируя, этот модуль делает поддержку nested groups, раскрывая их во
> время исполнения.
> Модуль написан на C++ и в любое приложение в системе тянет за собой
> /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
...и отъедает 1 мб памяти на десктопе, если до этого там не было
запущено ни одного с++ приложения.
Сколько у нас дасктопов без единого С++ приложения? Альтератор для
своего ГУЯ тоже будет тянуть /usr/lib/libstdc++.so.6.0.10 и что?

> Теперь главный вопрос: чем не устраивает поддержка RFC2307bis в
> nss_ldap? Она существует с 2002 года и отлично работает.
Гм, а как сетевые группы соотносятся с моим приложением? Вы его хоть
прочитали? Или вы предлагаете вместо того чтобы тянуть зависимость на
С++ поставить всем локально ldap?

> --
> / Alexander Bokovoy
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Alexander Bokovoy]

2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> 14 ноября 2008 г. 21:01 пользователь Alexander Bokovoy
> <ab@altlinux.org> написал:
>> 2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
>>> Можно придумать и более интересные применения этого модуля. Может
>>> стоит нам использовать его возможности по умолчанию? Соответственно
>>> исправить альтератор для работы с ним.
>> Суммируя, этот модуль делает поддержку nested groups, раскрывая их во
>> время исполнения.
>> Модуль написан на C++ и в любое приложение в системе тянет за собой
>> /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
> ...и отъедает 1 мб памяти на десктопе, если до этого там не было
> запущено ни одного с++ приложения.
> Сколько у нас дасктопов без единого С++ приложения? Альтератор для
> своего ГУЯ тоже будет тянуть /usr/lib/libstdc++.so.6.0.10 и что?
Можно отвечать по существу, а не заниматься флеймом?

>> Теперь главный вопрос: чем не устраивает поддержка RFC2307bis в
>> nss_ldap? Она существует с 2002 года и отлично работает.
> Гм, а как сетевые группы соотносятся с моим приложением? Вы его хоть
> прочитали? Или вы предлагаете вместо того чтобы тянуть зависимость на
> С++ поставить всем локально ldap?
Можно отвечать по существу, а не заниматься флеймом?

Я прочитал обоснование, которое в качестве примеров приводит типичные
примеры администрирования однообразных машин в организациях. Нигде там
не приведен use case, который специфичен для одного компьютера, везде
речь идет об "администрировании большого парка компьютеров и большого
числа пользователей". Указанные задачи хорошо решаются с помощью уже
существующего решения (LDAP/nss_ldap и RFC 2307bis) около пяти-шести
лет.

Аналогичный механизм существует и для CIFS. Поэтому, если в
организации инфраструктура выстраивается на основе LDAP/kerberos или
AD/CIFS (что с помощью решений от Microsoft, что с помощью Самбы), то
необходимый функционал там присутствует и может быть использован уже
существующими средствами.
-- 
/ Alexander Bokovoy

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 21:49 пользователь Alexander Bokovoy
<ab@altlinux.org> написал:
> Можно отвечать по существу, а не заниматься флеймом?
>
> Я прочитал обоснование, которое в качестве примеров приводит типичные
> примеры администрирования однообразных машин в организациях. Нигде там
> не приведен use case, который специфичен для одного компьютера, везде
> речь идет об "администрировании большого парка компьютеров и большого
> числа пользователей". Указанные задачи хорошо решаются с помощью уже
> существующего решения (LDAP/nss_ldap и RFC 2307bis) около пяти-шести
> лет.
А теперь прочитайте мое первое сообщение. Там предложение, где это
можно применить в AltLinux при отсутствии "большого парка" и прочего.
Я предложил просто использовать этот модуль в AltLinux Desktop, а вы
полесли что-то про сеть и ldap.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Evgeny Sinelnikov]

14 ноября 2008 г. 22:11 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> 14 ноября 2008 г. 21:49 пользователь Alexander Bokovoy
> <ab@altlinux.org> написал:
>> Можно отвечать по существу, а не заниматься флеймом?
>>
>> Я прочитал обоснование, которое в качестве примеров приводит типичные
>> примеры администрирования однообразных машин в организациях. Нигде там
>> не приведен use case, который специфичен для одного компьютера, везде
>> речь идет об "администрировании большого парка компьютеров и большого
>> числа пользователей". Указанные задачи хорошо решаются с помощью уже
>> существующего решения (LDAP/nss_ldap и RFC 2307bis) около пяти-шести
>> лет.
> А теперь прочитайте мое первое сообщение. Там предложение, где это
> можно применить в AltLinux при отсутствии "большого парка" и прочего.

Подтверждаю и привожу ниже ;)

14 ноября 2008 г. 19:53 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> Для нормальной работы пользователям в Linux необходимо являться членом
> некоторых групп, например cdwriter, audio.
>
> Сейчас модуль альтератора создающий пользователей добавляет их в эти
> группы автоматически. Этот список жестко забит в исходниках модуля и
> не позволяет управлять этим процессом.
>

Было бы неплохо в этом плане определить несколько групп (в нашей
терминологии ролей) и прибить их гвоздями. А остальные группы, которые
расчитаны на предоставление тех или иных привилегий просто вносить в
эти группы по мере необходимости и в зависимости от выбранной
политики.

Например, я считаю, что после установки virtualbox vboxusers мог бы
автоматически вноситься в группу users, а с помощью дополнительной
ручки, напрмиер conrtrol, мог бы переключаться. Варианты переключения
с именем и описанием, я и называю отдельной политикой.

Пример номер два. Анаолгично тому как vboxusers может вноситься, по
умолчанию, в группу users, группа tcpdump может вноситься в группу
admins и также переключаться политикой.

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


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Управление группами пользователя

[Alexander Bokovoy]

2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> 14 ноября 2008 г. 21:49 пользователь Alexander Bokovoy
> <ab@altlinux.org> написал:
>> Можно отвечать по существу, а не заниматься флеймом?
>>
>> Я прочитал обоснование, которое в качестве примеров приводит типичные
>> примеры администрирования однообразных машин в организациях. Нигде там
>> не приведен use case, который специфичен для одного компьютера, везде
>> речь идет об "администрировании большого парка компьютеров и большого
>> числа пользователей". Указанные задачи хорошо решаются с помощью уже
>> существующего решения (LDAP/nss_ldap и RFC 2307bis) около пяти-шести
>> лет.
> А теперь прочитайте мое первое сообщение. Там предложение, где это
> можно применить в AltLinux при отсутствии "большого парка" и прочего.
> Я предложил просто использовать этот модуль в AltLinux Desktop, а вы
> полесли что-то про сеть и ldap.
Я прочитал содержимое сайта, на который было указано, а также код и
задал резонные вопросы. Ответы на которые так и не получил.

Что касается использования в ALD, мое личное мнение -- не
использовать. На одной машине сложность поддержания локальной
конфигурации в обоих вариантах примерно сопоставима и значительно выше
поддержания аналогичных настроек в рамках SELinux, с которым придется
интегрироваться в недалеком будущем, а для сетевых инсталляций есть
более стандартное решение.

Как Вы собираетесь решать проблему множественного присутствия одно и
того же ID в списке после раскрытия групп?
Где проверки на превышение {NGROUP_MAX}?

-- 
/ Alexander Bokovoy

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 22:45 пользователь Alexander Bokovoy
<ab@altlinux.org> написал:
> Что касается использования в ALD, мое личное мнение -- не
> использовать. На одной машине сложность поддержания локальной
> конфигурации в обоих вариантах примерно сопоставима и значительно выше
> поддержания аналогичных настроек в рамках SELinux, с которым придется
> интегрироваться в недалеком будущем, а для сетевых инсталляций есть
> более стандартное решение.
Я думаю комунити учтет ваше мнение.

> Как Вы собираетесь решать проблему множественного присутствия одно и
> того же ID в списке после раскрытия групп?
Такого присутствия не наблюдается в случае использования данного
модуля. Каждый идентификатор присутствует единожды.

> Где проверки на превышение {NGROUP_MAX}?
Спасибо за обнаружанный недочет. Мы подумаем, что с этим сделать.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 21:11:07 Dmitriy M. Maslennikov wrote:
> 14 ноября 2008 г. 21:49 пользователь Alexander Bokovoy
>
> <ab@altlinux.org> написал:
> > Можно отвечать по существу, а не заниматься флеймом?
> >
> > Я прочитал обоснование, которое в качестве примеров приводит типичные
> > примеры администрирования однообразных машин в организациях. Нигде там
> > не приведен use case, который специфичен для одного компьютера, везде
> > речь идет об "администрировании большого парка компьютеров и большого
> > числа пользователей". Указанные задачи хорошо решаются с помощью уже
> > существующего решения (LDAP/nss_ldap и RFC 2307bis) около пяти-шести
> > лет.
>
> А теперь прочитайте мое первое сообщение. Там предложение, где это
> можно применить в AltLinux при отсутствии "большого парка" и прочего.
> Я предложил просто использовать этот модуль в AltLinux Desktop, а вы
> полесли что-то про сеть и ldap.

Пожалуйста, не надо это на Desktop.

-- 
Led

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 22:55 пользователь Led <ledest@gmail.com> написал:
> Пожалуйста, не надо это на Desktop.
А можете пояснить почему? Мне кажется, что строка c default_groups в
alterator-users выглядит, как весьма негибкое и костыльное решение.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 21:56:59 Dmitriy M. Maslennikov wrote:
> 14 ноября 2008 г. 22:55 пользователь Led <ledest@gmail.com> написал:
> > Пожалуйста, не надо это на Desktop.
>
> А можете пояснить почему? Мне кажется, что строка c default_groups в
> alterator-users выглядит, как весьма негибкое и костыльное решение.

Потому, что если не нравится модуль альтератора, нужно улучшать его (хотя, в 
случае с альтератором, это моветон), а не городить костыли. На десктопе эта 
штука - именно костыль.

-- 
Led

Re: [devel] Управление группами пользователя

[Stanislav Ievlev]

On Fri, Nov 14, 2008 at 10:01:13PM +0200, Led wrote:
> On Friday, 14 November 2008 21:56:59 Dmitriy M. Maslennikov wrote:
> > 14 ноября 2008 г. 22:55 пользователь Led <ledest@gmail.com> написал:
> > > Пожалуйста, не надо это на Desktop.
> >
> > А можете пояснить почему? Мне кажется, что строка c default_groups в
> > alterator-users выглядит, как весьма негибкое и костыльное решение.
> 
> Потому, что если не нравится модуль альтератора, нужно улучшать его (хотя, в 
> случае с альтератором, это моветон
г-н led@, с этого места пожалуйста поподробнее.

Re: [devel] Управление группами пользователя

[Pavlov Konstantin]

On Fri, Nov 14, 2008 at 11:07:41PM +0300, Stanislav Ievlev wrote:
> On Fri, Nov 14, 2008 at 10:01:13PM +0200, Led wrote:
> > On Friday, 14 November 2008 21:56:59 Dmitriy M. Maslennikov wrote:
> > > 14 ноября 2008 г. 22:55 пользователь Led <ledest@gmail.com> написал:
> > > > Пожалуйста, не надо это на Desktop.
> > >
> > > А можете пояснить почему? Мне кажется, что строка c default_groups в
> > > alterator-users выглядит, как весьма негибкое и костыльное решение.
> > 
> > Потому, что если не нравится модуль альтератора, нужно улучшать его (хотя, в 
> > случае с альтератором, это моветон
> г-н led@, с этого места пожалуйста поподробнее.

Не буду отвечать за г-на led@, но общее впечатление скорее такое, что
необходимо быть разработчиком alterator, чтобы писать к нему модули, в
связи с чем не очень понятно, стоит ли изобретать решения на его базе,
имея подходы к снаряду раз этак в полгода.

-- 
Это явно бага, но вот где -- не знаю.
		-- mike in community@

Re: [devel] Управление группами пользователя

[Stanislav Ievlev]

On Fri, Nov 14, 2008 at 11:10:39PM +0300, Pavlov Konstantin wrote:
> On Fri, Nov 14, 2008 at 11:07:41PM +0300, Stanislav Ievlev wrote:
> > On Fri, Nov 14, 2008 at 10:01:13PM +0200, Led wrote:
> > > On Friday, 14 November 2008 21:56:59 Dmitriy M. Maslennikov wrote:
> > > > 14 ноября 2008 г. 22:55 пользователь Led <ledest@gmail.com> написал:
> > > > > Пожалуйста, не надо это на Desktop.
> > > >
> > > > А можете пояснить почему? Мне кажется, что строка c default_groups в
> > > > alterator-users выглядит, как весьма негибкое и костыльное решение.
> > > 
> > > Потому, что если не нравится модуль альтератора, нужно улучшать его (хотя, в 
> > > случае с альтератором, это моветон
> > г-н led@, с этого места пожалуйста поподробнее.
> 
> Не буду отвечать за г-на led@, но общее впечатление скорее такое, что
> необходимо быть разработчиком alterator, чтобы писать к нему модули, в
> связи с чем не очень понятно, стоит ли изобретать решения на его базе,
> имея подходы к снаряду раз этак в полгода.
Не совсем верно.
Для того чтобы писать к нему бакенды не надо быть разработчиком alterator.

Вот с UI - другое дело. С этим вечные проблемы: 
* UI более скудный язык чем commandline и то что просто было в скрипте не хочет в него ложиться.
* нет идеальных средств разработки UI, всем всегда что-то не нравится ;)
* большиство людей не умеют делать UI ;)

Но мы боремся ;)

А лучше вместо впечатлений реальные преложения в devel-conf@ ;)

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 22:10:39 Pavlov Konstantin wrote:
> On Fri, Nov 14, 2008 at 11:07:41PM +0300, Stanislav Ievlev wrote:
> > On Fri, Nov 14, 2008 at 10:01:13PM +0200, Led wrote:
> > > On Friday, 14 November 2008 21:56:59 Dmitriy M. Maslennikov wrote:
> > > > 14 ноября 2008 г. 22:55 пользователь Led <ledest@gmail.com> написал:
> > > > > Пожалуйста, не надо это на Desktop.
> > > >
> > > > А можете пояснить почему? Мне кажется, что строка c default_groups в
> > > > alterator-users выглядит, как весьма негибкое и костыльное решение.
> > >
> > > Потому, что если не нравится модуль альтератора, нужно улучшать его
> > > (хотя, в случае с альтератором, это моветон
> >
> > г-н led@, с этого места пожалуйста поподробнее.
>
> Не буду отвечать за г-на led@, но общее впечатление скорее такое, что
> необходимо быть разработчиком alterator, чтобы писать к нему модули, в
> связи с чем не очень понятно, стоит ли изобретать решения на его базе,
> имея подходы к снаряду раз этак в полгода.

И я бы не стал обвинять в этом г-на inger'а. Значит alterator был именно так 
задуман. Или таким получился. Но критиковать его (alterator) у меня нет 
желания и повода. Просто в моей практике он бесполезен (в таком виде, как он 
задуман/получился) :(

-- 
Led

Re: [devel] Управление группами пользователя

[Stanislav Ievlev]

On Fri, Nov 14, 2008 at 10:24:08PM +0200, Led wrote:
> On Friday, 14 November 2008 22:10:39 Pavlov Konstantin wrote:
> > On Fri, Nov 14, 2008 at 11:07:41PM +0300, Stanislav Ievlev wrote:
> > > On Fri, Nov 14, 2008 at 10:01:13PM +0200, Led wrote:
> > > > On Friday, 14 November 2008 21:56:59 Dmitriy M. Maslennikov wrote:
> > > > > 14 ноября 2008 г. 22:55 пользователь Led <ledest@gmail.com> написал:
> > > > > > Пожалуйста, не надо это на Desktop.
> > > > >
> > > > > А можете пояснить почему? Мне кажется, что строка c default_groups в
> > > > > alterator-users выглядит, как весьма негибкое и костыльное решение.
> > > >
> > > > Потому, что если не нравится модуль альтератора, нужно улучшать его
> > > > (хотя, в случае с альтератором, это моветон
> > >
> > > г-н led@, с этого места пожалуйста поподробнее.
> >
> > Не буду отвечать за г-на led@, но общее впечатление скорее такое, что
> > необходимо быть разработчиком alterator, чтобы писать к нему модули, в
> > связи с чем не очень понятно, стоит ли изобретать решения на его базе,
> > имея подходы к снаряду раз этак в полгода.
> 
> И я бы не стал обвинять в этом г-на inger'а. Значит alterator был именно так 
> задуман. Или таким получился. Но критиковать его (alterator) у меня нет 
> желания и повода. Просто в моей практике он бесполезен (в таком виде, как он 
> задуман/получился) :(
Естественно он развивался так как это было нужно тем кто им пользовался ;)

В прочем я не устаю всем тут повторять одно и тоже.
"Оно постоянно изменяется, вы все можете на это повлиять". 

И чур не надо сразу же при этом отвечать, что тут всё надо полностью переписывать ;)
Многие полезные вещи, прозвучавшие в devel-conf@ уже сделаны или находятся в процессе
реализации, и alterator уже совсем не тот что был скажем год назад, в том
числе и в архитектурном плане.

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

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 23:24 пользователь Led <ledest@gmail.com> написал:
> И я бы не стал обвинять в этом г-на inger'а. Значит alterator был именно так
> задуман. Или таким получился. Но критиковать его (alterator) у меня нет
> желания и повода. Просто в моей практике он бесполезен (в таком виде, как он
> задуман/получился) :(
Я бы попросил не обсуждать здесь alterator. Он возник здесь только как
наглядный пример данной проблемы. И он ее решать не должем, поэтому
разработчик модуля работы с пользователями просто захардкодил список
групп по-умолчанию. Это костыл, который появился там потому, что не
существует нормального решения. Мы его предлагаем в рамках нашего
видения проблемы.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Денис Смирнов]

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

On Fri, Nov 14, 2008 at 11:29:59PM +0300, Dmitriy M. Maslennikov wrote:

>> И я бы не стал обвинять в этом г-на inger'а. Значит alterator был именно так
>> задуман. Или таким получился. Но критиковать его (alterator) у меня нет
>> желания и повода. Просто в моей практике он бесполезен (в таком виде, как он
>> задуман/получился) :(
DMM> Я бы попросил не обсуждать здесь alterator. Он возник здесь только как
DMM> наглядный пример данной проблемы. И он ее решать не должем, поэтому
DMM> разработчик модуля работы с пользователями просто захардкодил список
DMM> групп по-умолчанию. Это костыл, который появился там потому, что не
DMM> существует нормального решения. Мы его предлагаем в рамках нашего
DMM> видения проблемы.

Решение интересное.
Использование C++ в данном случае несколько неудачное решения именно из-за
отсутствия libstdc++ в /lib. Поэтому для сервера это решение слабопригодно
(но пригодно!) а типичные десктопные задачи с тем чтобы добавить
пользователя во все необходимые группы -- решает более удачно чем другие
средства.

Да, мне этот инструмент кажется полезным но думаю потребуется помочь ldv@
чтобы подобное задействовать -- все-таки это системообразующий пакет.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

15 ноября 2008 г. 1:00 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> Решение интересное.
> Использование C++ в данном случае несколько неудачное решения именно из-за
> отсутствия libstdc++ в /lib. Поэтому для сервера это решение слабопригодно
> (но пригодно!) а типичные десктопные задачи с тем чтобы добавить
> пользователя во все необходимые группы -- решает более удачно чем другие
> средства.
Единственное неудобство располажения библиотеки в /usr/lib - возможная
недоступность его на ранних этапах загрузки системы. В этом случае
модуль просто не работает. Впрочем на ранних этапах он и не нужен, а
нужен только к приглашению ко входу в систему. Впрочем переписываение
его без лишних зависимосте не настолько большая проблема, чтобы о ней
без конца повторять. В первую очередь для нас важна была скорость
разработки.

> Да, мне этот инструмент кажется полезным но думаю потребуется помочь ldv@
> чтобы подобное задействовать -- все-таки это системообразующий пакет.
Так вот и ждем его мнения.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Stanislav Ievlev]

On Sat, Nov 15, 2008 at 09:29:42AM +0300, Dmitriy M. Maslennikov wrote:
> 15 ноября 2008 г. 1:00 пользователь Денис Смирнов
> <mithraen@altlinux.ru> написал:
> > Решение интересное.
> > Использование C++ в данном случае несколько неудачное решения именно из-за
> > отсутствия libstdc++ в /lib. Поэтому для сервера это решение слабопригодно
> > (но пригодно!) а типичные десктопные задачи с тем чтобы добавить
> > пользователя во все необходимые группы -- решает более удачно чем другие
> > средства.
> Единственное неудобство располажения библиотеки в /usr/lib - возможная
> недоступность его на ранних этапах загрузки системы. В этом случае
> модуль просто не работает. Впрочем на ранних этапах он и не нужен, а
> нужен только к приглашению ко входу в систему. Впрочем переписываение
> его без лишних зависимосте не настолько большая проблема, чтобы о ней
> без конца повторять. В первую очередь для нас важна была скорость
> разработки.
> 
> > Да, мне этот инструмент кажется полезным но думаю потребуется помочь ldv@
> > чтобы подобное задействовать -- все-таки это системообразующий пакет.
> Так вот и ждем его мнения.
Я так понимаю C++ использовался потому что там можно строить более удобные структуры данных?
Попробуйте посмотреть на хеш-таблицы в glibc и на glib2. Возможно понравится ;)
Последняя библиотека с некоторого времени лежит в /lib ибо её использует syslog-ng. Да и вообще
это хороший сборник 'велосипедов', хорошо восполняющий асектизм стандартного C.

Re: [devel] Управление группами пользователя

[Evgeny Sinelnikov]

16 ноября 2008 г. 17:40 пользователь Stanislav Ievlev
<inger@altlinux.org> написал:
> On Sat, Nov 15, 2008 at 09:29:42AM +0300, Dmitriy M. Maslennikov wrote:
>> 15 ноября 2008 г. 1:00 пользователь Денис Смирнов
>> <mithraen@altlinux.ru> написал:
>> > Решение интересное.
>> > Использование C++ в данном случае несколько неудачное решения именно из-за
>> > отсутствия libstdc++ в /lib. Поэтому для сервера это решение слабопригодно
>> > (но пригодно!) а типичные десктопные задачи с тем чтобы добавить
>> > пользователя во все необходимые группы -- решает более удачно чем другие
>> > средства.
>> Единственное неудобство располажения библиотеки в /usr/lib - возможная
>> недоступность его на ранних этапах загрузки системы. В этом случае
>> модуль просто не работает. Впрочем на ранних этапах он и не нужен, а
>> нужен только к приглашению ко входу в систему. Впрочем переписываение
>> его без лишних зависимосте не настолько большая проблема, чтобы о ней
>> без конца повторять. В первую очередь для нас важна была скорость
>> разработки.
>>
>> > Да, мне этот инструмент кажется полезным но думаю потребуется помочь ldv@
>> > чтобы подобное задействовать -- все-таки это системообразующий пакет.
>> Так вот и ждем его мнения.
> Я так понимаю C++ использовался потому что там можно строить более удобные структуры данных?

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

> Попробуйте посмотреть на хеш-таблицы в glibc и на glib2. Возможно понравится ;)

Пробовал... Не нравится ;)
Я мыслю категориями, которые, для меня, легче выражаются языковыми
конструкциями в C++, чем в С... Для борцов за "чистоту", к сожалению,
я такой не один....

> Последняя библиотека с некоторого времени лежит в /lib ибо её использует syslog-ng. Да и вообще
> это хороший сборник 'велосипедов', хорошо восполняющий асектизм стандартного C.
>

Всё-таки почему glib2 получил право на переезд в /lib, а у libstdc++
есть такие проблемы? Этому есть иные причины, чем увеличение объёма
базовой системы?


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Управление группами пользователя

[Alexander Bokovoy]

2008/11/16 Evgeny Sinelnikov <sin@altlinux.ru>:
> Пробовал... Не нравится ;)
> Я мыслю категориями, которые, для меня, легче выражаются языковыми
> конструкциями в C++, чем в С... Для борцов за "чистоту", к сожалению,
> я такой не один....
Посмотрите на Vala как на пример высокоуровневого языка, использующего
для выражения средства glib2. Vala написана на самой себе, так что
качестве примера довольно выразительна.

>> Последняя библиотека с некоторого времени лежит в /lib ибо её использует syslog-ng. Да и вообще
>> это хороший сборник 'велосипедов', хорошо восполняющий асектизм стандартного C.
>>
>
> Всё-таки почему glib2 получил право на переезд в /lib, а у libstdc++
> есть такие проблемы? Этому есть иные причины, чем увеличение объёма
> базовой системы?
У меня тоже есть пожелание к переезду libstdc++ в /lib.

Впрочем, от необдуманного написания кода это не спасает и "легче
выражаются языковыми конструкциями" вряди может служить в качестве
обоснования при написании низкоуровневых компонент, критичность
которых довольно высока. Я не говорю уже про втягивание pthreads во
все приложения, которые могут быть и не готовы к этому. Один такой
пример плохой реализации внутри glibc мы уже видели
(http://samba.org/~tridge/junkcode/aio_uid.c).

Главное, что я хотел продемонстрировать в этом обсуждении и что вы с
Дмитрием так пока и не поняли, что архитектурные и дизайнерские
решения не всегда принимаются на основании личных предпочтений. Прежде
всего необходимо думать о тех, кто использует разработанное. В случае
компонент ОС это прежде всего другие приложения и принцип "не навреди"
здесь играет главенствующую роль.
-- 
/ Alexander Bokovoy

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

16 ноября 2008 г. 18:54 пользователь Alexander Bokovoy
<ab@altlinux.org> написал:
> Посмотрите на Vala как на пример высокоуровневого языка, использующего
> для выражения средства glib2. Vala написана на самой себе, так что
> качестве примера довольно выразительна.
Я не спорю, что вокруг glib2 можно построить высокоуровневую систему.
Но это уже не С. Я полагаю, что вы не предлагаете нам написать модул
на vala?

> У меня тоже есть пожелание к переезду libstdc++ в /lib.
>
> Впрочем, от необдуманного написания кода это не спасает и "легче
> выражаются языковыми конструкциями" вряди может служить в качестве
> обоснования при написании низкоуровневых компонент, критичность
> которых довольно высока.
Легче выражается -> меньше шансов допустить ошибку.

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

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

> Я не говорю уже про втягивание pthreads во
> все приложения, которые могут быть и не готовы к этому. Один такой
> пример плохой реализации внутри glibc мы уже видели
> (http://samba.org/~tridge/junkcode/aio_uid.c).
Да, на втягивании pthread в модуль (другой) мы уже наступали. В старом
тулчейне gettext переставал работать)

> Главное, что я хотел продемонстрировать в этом обсуждении и что вы с
> Дмитрием так пока и не поняли, что архитектурные и дизайнерские
> решения не всегда принимаются на основании личных предпочтений. Прежде
> всего необходимо думать о тех, кто использует разработанное. В случае
> компонент ОС это прежде всего другие приложения и принцип "не навреди"
> здесь играет главенствующую роль.
Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
конструктивную критику, а не заявления, типа, "плох и все".

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Andrey Rahmatullin]

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

On Sun, Nov 16, 2008 at 07:39:08PM +0300, Dmitriy M. Maslennikov wrote:
> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
> конструктивную критику, а не заявления, типа, "плох и все".
http://yosefk.com/c++fqa/ ? :)

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

 * Maks|home успел съездить в соседний город, а тут всё ещё про sql

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

Re: [devel] Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 21:50:13 16.11.2008 UTC+05 when wrar@altlinux.ru did gyre and gimble:

 >> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
 >> конструктивную критику, а не заявления, типа, "плох и все".
 AR> http://yosefk.com/c++fqa/ ? :)

Это замечания к C++ как таковому, а не как к C++ как языку реализации
низкоуровневых компонентов операционной системы.

-- 

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

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

16 ноября 2008 г. 19:50 пользователь Andrey Rahmatullin
<wrar@altlinux.ru> написал:
> On Sun, Nov 16, 2008 at 07:39:08PM +0300, Dmitriy M. Maslennikov wrote:
>> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
>> конструктивную критику, а не заявления, типа, "плох и все".
> http://yosefk.com/c++fqa/ ? :)
Основные проблемы, я так понял по ссылке:
http://yosefk.com/c++fqa/defective.html
По пунктам:
- No compile time encapsulation
  Это верно и для С, и для всех компилируемых языков, которые я знаю. А где это
  есть? В С++ проблему обходят создавая для кождого класса foo класс fooPrivate,
  и помещая в основной ссылку на него.
- Outstandingly complicated grammar
 Проблема писателей компиляторов. Очень плохо, не спорю, но сейчас
 уже недостатка в качественных компиляторах С++ не ощущается.
- No way to locate definitions
 ИМХО, небольшая проблема, впрочем характерная и для С.
- No run time encapsulation
 Что ж для кого-то факт того, что С++ - unmanaged - проблема, для кого-то -
 достоинство. Впрочем, к С это так же относится.
- No binary implementation rules
 Так как у нас используется только один компилятор gcc-c++, то эта проблема
 несущественна. В случае использования нескольких компиляторов, да, мне
 это тоже не нравится.
- No reflection
 Ну что ж теперь. Нет, так нет) У С тоже reflection нет.
- Very complicated type system
 Да, С++ сложный язык, никто не спорит. Даже черезчур, согласен.
- Very complicated type-based binding rules
 Опять жалоба на то, что типов много, что при перегруженных функциях может
 породит несколько экранов ошибок. Ну что ж, за гибкость надо платить.
- Defective operator overloading
 По сути говорят, что переопределять операторы так сложно, что мы ошибаемся
 и у нас течет память и прочее. Что ж, не перегружайте).
- Defective exceptions
 Не совсем понял суть притензий к исключениям...
- Duplicate facilities
 На мой взгляд - не проблема. Проблема только на этапах обучения. Ну и
 нехорошо, конечно, что многие библиотеки создают собственные строки,
 списки и подобное. Впрочем в С это тоже делается для каждого проекта.
- No high-level built-in types
 Притензия к тому, что из-за того, что все высокоуровневые возможности не
 встроены в язык, а реализованы на нем, нельзя инициализировать списки в
 исходном коде коде, ну и как всегда: "компилятор выдает много ошибок".
 Не считаю проблемой.
- Manual memory management
 Извечный и очень спорный вопрос, впрочем в С тоже памятью управляют
 вручную.
- Defective metaprogramming facilities
 Ругают С макросы (именно ими метапрограммируется NSS :)) ). К счастью в
 С++ это убожество не используется. Метапрограммирование на шаблонах
 ругают так же. Если вспомнить историю, то создавались они не для этого, а
 для обобщенного программирования. Метапрограммирование -- побочный
 эффект, странно ожидать, что он случайно идеально впишется в систему.
 Впрочем, то, что оно есть -- это хорошо.
- Unhelpful standard library
 Будем считать, что boost -- стандартная библиотека С++. А, вообще, в
 случае создания довольно жирного десктопа (как в нашем случае)
 недостатка в библиотеках на С++ не ощущается. Кроме того, доступны все
 библиотеки для С.
- Defective inlining
 Ну некоторая придирка. Впрочем в С - тоже самое (если мы используем
 макросы как функции)
- Implicitly called & generated functions
 Опять не уловил сути. Устал читать, видимо. Впрочем, все придирки
 довольно стандартны.

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

Вопрос остается открытым: почему нельзя писать системные компоненты на С++?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Andrey Rahmatullin]

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

On Sun, Nov 16, 2008 at 08:46:38PM +0300, Dmitriy M. Maslennikov wrote:
> - Defective exceptions
>  Не совсем понял суть притензий к исключениям...
"претензий"
http://yosefk.com/c++fqa/exceptions.html

>  Будем считать, что boost -- стандартная библиотека С++. А, вообще, в
>  случае создания довольно жирного десктопа (как в нашем случае)
В вашем случае не десктоп, вам же сказали.

> Вывод: С++ единственный язык полностью совместимый с С
Не полностью.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<thresh> не знаю, где mysql ab зарегено
<swi> thresh: ab обычно немчура...
<thresh> ab: ты немец? :)

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

Re: [devel] Управление группами пользователя

[Evgeny Sinelnikov]

16 ноября 2008 г. 20:46 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> 16 ноября 2008 г. 19:50 пользователь Andrey Rahmatullin
> <wrar@altlinux.ru> написал:
>> On Sun, Nov 16, 2008 at 07:39:08PM +0300, Dmitriy M. Maslennikov wrote:
>>> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
>>> конструктивную критику, а не заявления, типа, "плох и все".
>> http://yosefk.com/c++fqa/ ? :)
> Основные проблемы, я так понял по ссылке:
> http://yosefk.com/c++fqa/defective.html
> По пунктам:
> - No compile time encapsulation
>  Это верно и для С, и для всех компилируемых языков, которые я знаю. А где это
>  есть? В С++ проблему обходят создавая для кождого класса foo класс fooPrivate,
>  и помещая в основной ссылку на него.
> - Outstandingly complicated grammar
>  Проблема писателей компиляторов. Очень плохо, не спорю, но сейчас
>  уже недостатка в качественных компиляторах С++ не ощущается.
> - No way to locate definitions
>  ИМХО, небольшая проблема, впрочем характерная и для С.
> - No run time encapsulation
>  Что ж для кого-то факт того, что С++ - unmanaged - проблема, для кого-то -
>  достоинство. Впрочем, к С это так же относится.
> - No binary implementation rules
>  Так как у нас используется только один компилятор gcc-c++, то эта проблема
>  несущественна. В случае использования нескольких компиляторов, да, мне
>  это тоже не нравится.
> - No reflection
>  Ну что ж теперь. Нет, так нет) У С тоже reflection нет.
> - Very complicated type system
>  Да, С++ сложный язык, никто не спорит. Даже черезчур, согласен.
> - Very complicated type-based binding rules
>  Опять жалоба на то, что типов много, что при перегруженных функциях может
>  породит несколько экранов ошибок. Ну что ж, за гибкость надо платить.
> - Defective operator overloading
>  По сути говорят, что переопределять операторы так сложно, что мы ошибаемся
>  и у нас течет память и прочее. Что ж, не перегружайте).
> - Defective exceptions
>  Не совсем понял суть притензий к исключениям...
> - Duplicate facilities
>  На мой взгляд - не проблема. Проблема только на этапах обучения. Ну и
>  нехорошо, конечно, что многие библиотеки создают собственные строки,
>  списки и подобное. Впрочем в С это тоже делается для каждого проекта.
> - No high-level built-in types
>  Притензия к тому, что из-за того, что все высокоуровневые возможности не
>  встроены в язык, а реализованы на нем, нельзя инициализировать списки в
>  исходном коде коде, ну и как всегда: "компилятор выдает много ошибок".
>  Не считаю проблемой.
> - Manual memory management
>  Извечный и очень спорный вопрос, впрочем в С тоже памятью управляют
>  вручную.
> - Defective metaprogramming facilities
>  Ругают С макросы (именно ими метапрограммируется NSS :)) ). К счастью в
>  С++ это убожество не используется. Метапрограммирование на шаблонах
>  ругают так же. Если вспомнить историю, то создавались они не для этого, а
>  для обобщенного программирования. Метапрограммирование -- побочный
>  эффект, странно ожидать, что он случайно идеально впишется в систему.
>  Впрочем, то, что оно есть -- это хорошо.
> - Unhelpful standard library
>  Будем считать, что boost -- стандартная библиотека С++. А, вообще, в
>  случае создания довольно жирного десктопа (как в нашем случае)
>  недостатка в библиотеках на С++ не ощущается. Кроме того, доступны все
>  библиотеки для С.
> - Defective inlining
>  Ну некоторая придирка. Впрочем в С - тоже самое (если мы используем
>  макросы как функции)
> - Implicitly called & generated functions
>  Опять не уловил сути. Устал читать, видимо. Впрочем, все придирки
>  довольно стандартны.
>
> Вывод: С++ единственный язык полностью совместимый с С, но позволяющий
> оперировать высокоуровневыми конструкциями. Поэтому он прочно занял
> свою нишу, и я, таки, считаю, что он является прекрасной заменой С, в
> случае, если умело им пользоваться. Но из-за своей сложности он
> требует длительного изучения.
>
> Вопрос остается открытым: почему нельзя писать системные компоненты на С++?
>

После долго разговора в #altlinux, мне кажется, что я понял... :)

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

Так вот линковка системного модуля с libstdc++ одного ABI, который при
этом грузится динамически, потенциально может быть критична для тех
приложений, которые слинкованы с libstdc++ другого ABI. Это, вероятно,
может проявится и в случае со статической линковкой. Это можно и нужно
проверять, но проблема вроде бы очевидна, хотя детали мне не ясны -
буду смотреть... Не понятно тогда, а как же обходятся пропиетарные
приложения, линкуясь со старыми версиями GLIBC - ведь работают же :)

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

В общем, вопрос ставится так: "Крайне не желательно писать NSS-модули
на C++". Это связано в особенностями архитекутры NSS. Мне теперь надо
обдумать этот вопрос...

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

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Управление группами пользователя

[Led]

On Sunday, 16 November 2008 20:39:12 Evgeny Sinelnikov wrote:
> 16 ноября 2008 г. 20:46 пользователь Dmitriy M. Maslennikov
>
> <maslennikovdm@gmail.com> написал:
> > 16 ноября 2008 г. 19:50 пользователь Andrey Rahmatullin
> >
> > <wrar@altlinux.ru> написал:
> >> On Sun, Nov 16, 2008 at 07:39:08PM +0300, Dmitriy M. Maslennikov wrote:
> >>> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
> >>> конструктивную критику, а не заявления, типа, "плох и все".
> >>
> >> http://yosefk.com/c++fqa/ ? :)
> >
> > Основные проблемы, я так понял по ссылке:
> > http://yosefk.com/c++fqa/defective.html
> > По пунктам:
> > - No compile time encapsulation
> >  Это верно и для С, и для всех компилируемых языков, которые я знаю. А
> > где это есть? В С++ проблему обходят создавая для кождого класса foo
> > класс fooPrivate, и помещая в основной ссылку на него.
> > - Outstandingly complicated grammar
> >  Проблема писателей компиляторов. Очень плохо, не спорю, но сейчас
> >  уже недостатка в качественных компиляторах С++ не ощущается.
> > - No way to locate definitions
> >  ИМХО, небольшая проблема, впрочем характерная и для С.
> > - No run time encapsulation
> >  Что ж для кого-то факт того, что С++ - unmanaged - проблема, для кого-то
> > - достоинство. Впрочем, к С это так же относится.
> > - No binary implementation rules
> >  Так как у нас используется только один компилятор gcc-c++, то эта
> > проблема несущественна. В случае использования нескольких компиляторов,
> > да, мне это тоже не нравится.
> > - No reflection
> >  Ну что ж теперь. Нет, так нет) У С тоже reflection нет.
> > - Very complicated type system
> >  Да, С++ сложный язык, никто не спорит. Даже черезчур, согласен.
> > - Very complicated type-based binding rules
> >  Опять жалоба на то, что типов много, что при перегруженных функциях
> > может породит несколько экранов ошибок. Ну что ж, за гибкость надо
> > платить. - Defective operator overloading
> >  По сути говорят, что переопределять операторы так сложно, что мы
> > ошибаемся и у нас течет память и прочее. Что ж, не перегружайте).
> > - Defective exceptions
> >  Не совсем понял суть притензий к исключениям...
> > - Duplicate facilities
> >  На мой взгляд - не проблема. Проблема только на этапах обучения. Ну и
> >  нехорошо, конечно, что многие библиотеки создают собственные строки,
> >  списки и подобное. Впрочем в С это тоже делается для каждого проекта.
> > - No high-level built-in types
> >  Притензия к тому, что из-за того, что все высокоуровневые возможности не
> >  встроены в язык, а реализованы на нем, нельзя инициализировать списки в
> >  исходном коде коде, ну и как всегда: "компилятор выдает много ошибок".
> >  Не считаю проблемой.
> > - Manual memory management
> >  Извечный и очень спорный вопрос, впрочем в С тоже памятью управляют
> >  вручную.
> > - Defective metaprogramming facilities
> >  Ругают С макросы (именно ими метапрограммируется NSS :)) ). К счастью в
> >  С++ это убожество не используется. Метапрограммирование на шаблонах
> >  ругают так же. Если вспомнить историю, то создавались они не для этого,
> > а для обобщенного программирования. Метапрограммирование -- побочный
> > эффект, странно ожидать, что он случайно идеально впишется в систему.
> > Впрочем, то, что оно есть -- это хорошо.
> > - Unhelpful standard library
> >  Будем считать, что boost -- стандартная библиотека С++. А, вообще, в
> >  случае создания довольно жирного десктопа (как в нашем случае)
> >  недостатка в библиотеках на С++ не ощущается. Кроме того, доступны все
> >  библиотеки для С.
> > - Defective inlining
> >  Ну некоторая придирка. Впрочем в С - тоже самое (если мы используем
> >  макросы как функции)
> > - Implicitly called & generated functions
> >  Опять не уловил сути. Устал читать, видимо. Впрочем, все придирки
> >  довольно стандартны.
> >
> > Вывод: С++ единственный язык полностью совместимый с С, но позволяющий
> > оперировать высокоуровневыми конструкциями. Поэтому он прочно занял
> > свою нишу, и я, таки, считаю, что он является прекрасной заменой С, в
> > случае, если умело им пользоваться. Но из-за своей сложности он
> > требует длительного изучения.
> >
> > Вопрос остается открытым: почему нельзя писать системные компоненты на
> > С++?
>
> После долго разговора в #altlinux, мне кажется, что я понял... :)
>
> Проблема вот в чём. GCC и GLIBC - это стандартные компоненты. Но GLIBC
> считается первичной, а GCC могут быть разными.
>
> Так вот линковка системного модуля с libstdc++ одного ABI, который при
> этом грузится динамически, потенциально может быть критична для тех
> приложений, которые слинкованы с libstdc++ другого ABI. Это, вероятно,
> может проявится и в случае со статической линковкой. Это можно и нужно
> проверять, но проблема вроде бы очевидна, хотя детали мне не ясны -
> буду смотреть... Не понятно тогда, а как же обходятся пропиетарные
> приложения, линкуясь со старыми версиями GLIBC - ведь работают же :)
>
> В этой потенциальной проблеме, как я понял, и состоит конструктиваня
> критика технических аспектов реализации.
>
> В общем, вопрос ставится так: "Крайне не желательно писать NSS-модули
> на C++". Это связано в особенностями архитекутры NSS. Мне теперь надо
> обдумать этот вопрос...
>
> Я крайне разочарован тем, что вместо такого простого объяснения, мы
> два дня препирались о применимости C++, как системного языка. К
> сожалению, как мне кажется, призывая понять проблему, нас скорее
> провоцировали, чем указывали на неё...

ИМХО "препирались" здесь только вы. Теперь вы обвиняете ВСЕХ (кроме вас), что  
до вас так туго доходит.

-- 
Led

Re: [devel] Управление группами пользователя

[Evgeny Sinelnikov]

> ИМХО "препирались" здесь только вы. Теперь вы обвиняете ВСЕХ (кроме вас), что
> до вас так туго доходит.
>

Ну, как же, как же :)
Себя я вряд ли упрекну, хотя наверное есть в чём :)

А Дима, как мне кажется, стал "жертвой" провокации :))))))))
В общем, всё это не важно....

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

И советовать стоило это проверить, а не вести речь о том, что C++ не
системный... Просто текущая реализация системных компонент создана без
учёта использования C++... Да и как это реализвать тоже не понятно...

Я хотел бы повторить вопрос о том как же тогда работают пропиетарные
приложения со старым GLIBC? Или они никогда не обращаются к NSS?

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Управление группами пользователя

[Dmitry V. Levin]

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

On Sun, Nov 16, 2008 at 09:56:12PM +0300, Evgeny Sinelnikov wrote:
[...]
> Проблемы-то потенциальные, я ни разу не видел примеров, хотя не
> исключаю, что они есть... Я думаю, что это стоит проверить...

Я видел фатальные проблемы, кажется, при использовании кривого
(в обсуждаемом здесь смысле) libnss_ldap.

> И советовать стоило это проверить, а не вести речь о том, что C++ не
> системный... Просто текущая реализация системных компонент создана без
> учёта использования C++... Да и как это реализвать тоже не понятно...
> 
> Я хотел бы повторить вопрос о том как же тогда работают пропиетарные
> приложения со старым GLIBC? Или они никогда не обращаются к NSS?

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


-- 
ldv

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

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

А в сизифе есть пакеты собранные разными версиями gcc одновременно? А
то я не в курсе.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Alexander Bokovoy]

2008/11/16 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> А в сизифе есть пакеты собранные разными версиями gcc одновременно? А
> то я не в курсе.
gcc? Да. Весь Сизиф не пересобирается по каждой смене компилятора.
Например, есть пакеты, датированные 2005 годом сборки. Присутствуют и
собранные "старым" компилятором библиотеки, которые используются
собранными "новым компилятором" приложениями.

-- 
/ Alexander Bokovoy

Re: [devel] Управление группами пользователя

[Evgeny Sinelnikov]

16 ноября 2008 г. 22:42 пользователь Alexander Bokovoy
<ab@altlinux.org> написал:
> 2008/11/16 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
>> А в сизифе есть пакеты собранные разными версиями gcc одновременно? А
>> то я не в курсе.
> gcc? Да. Весь Сизиф не пересобирается по каждой смене компилятора.
> Например, есть пакеты, датированные 2005 годом сборки. Присутствуют и
> собранные "старым" компилятором библиотеки, которые используются
> собранными "новым компилятором" приложениями.
>

В смысле это та же проблема...

Только вот я в одном пока не разобрался... Разве статика не решает
этой проблемы... В смысле я вот никак не могу понять как себя поведёт
модуль собранный c libstdc++, а будет загружен приложением, которое
тоже слинковано _статически_ с libstdc++, но у которого другое ABI,
чем у модуля?



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Управление группами пользователя

[Alexander Bokovoy]

2008/11/16 Evgeny Sinelnikov <sin@altlinux.ru>:
> 16 ноября 2008 г. 22:42 пользователь Alexander Bokovoy
> <ab@altlinux.org> написал:
>> 2008/11/16 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
>>> А в сизифе есть пакеты собранные разными версиями gcc одновременно? А
>>> то я не в курсе.
>> gcc? Да. Весь Сизиф не пересобирается по каждой смене компилятора.
>> Например, есть пакеты, датированные 2005 годом сборки. Присутствуют и
>> собранные "старым" компилятором библиотеки, которые используются
>> собранными "новым компилятором" приложениями.
>>
>
> В смысле это та же проблема...
Нет.


> Только вот я в одном пока не разобрался... Разве статика не решает
> этой проблемы... В смысле я вот никак не могу понять как себя поведёт
> модуль собранный c libstdc++, а будет загружен приложением, которое
> тоже слинковано _статически_ с libstdc++, но у которого другое ABI,
> чем у модуля?
При чем здесь код, который производит gcc в сравнении с кодом, который
производит g++ и использует разные версии libstdc++ и разные версии
boost?

-- 
/ Alexander Bokovoy

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

16 ноября 2008 г. 22:57 пользователь Alexander Bokovoy
<ab@altlinux.org> написал:
>> Только вот я в одном пока не разобрался... Разве статика не решает
>> этой проблемы... В смысле я вот никак не могу понять как себя поведёт
>> модуль собранный c libstdc++, а будет загружен приложением, которое
>> тоже слинковано _статически_ с libstdc++, но у которого другое ABI,
>> чем у модуля?
> При чем здесь код, который производит gcc в сравнении с кодом, который
> производит g++ и использует разные версии libstdc++ и разные версии
> boost?
От boost легко оторваться, он там не критичен. Что же касается кода,
который производит gcc в сравнении с кодом g++, то, насколько я
понимаю, все отличие это то, что с++ делает кучу функций со сложными
нечитаемыми именами. Ну и добавляет слинкованной стандартную
библиотеку. В остальном отличий нет. Поправьте, если я не прав.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

16 ноября 2008 г. 22:42 пользователь Alexander Bokovoy
<ab@altlinux.org> написал:
> gcc? Да. Весь Сизиф не пересобирается по каждой смене компилятора.
> Например, есть пакеты, датированные 2005 годом сборки. Присутствуют и
> собранные "старым" компилятором библиотеки, которые используются
> собранными "новым компилятором" приложениями.
Но ведь тогда имеем ту же проблему: библиотека, слинкованная с одной
версией стандартной библиотеки с++, может быть использована программой
собранной с другой версией. Мы уже задавали вопрос по этому поводу в
рассылке в связи с обсуждаемым тогда shared library policy, и нам
ответили, что для такой ситуации необходимо что-то вроде
repocop-теста, который будет отслеживать подобные ситуации.

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

Тем не менее основной вопрос: нужен ли нам подобный модуль?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Alexander Bokovoy]

2008/11/16 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> 16 ноября 2008 г. 22:42 пользователь Alexander Bokovoy
> <ab@altlinux.org> написал:
>> gcc? Да. Весь Сизиф не пересобирается по каждой смене компилятора.
>> Например, есть пакеты, датированные 2005 годом сборки. Присутствуют и
>> собранные "старым" компилятором библиотеки, которые используются
>> собранными "новым компилятором" приложениями.
> Но ведь тогда имеем ту же проблему: библиотека, слинкованная с одной
> версией стандартной библиотеки с++, может быть использована программой
> собранной с другой версией. Мы уже задавали вопрос по этому поводу в
> рассылке в связи с обсуждаемым тогда shared library policy, и нам
> ответили, что для такой ситуации необходимо что-то вроде
> repocop-теста, который будет отслеживать подобные ситуации.
Вы постоянно смешиваете gcc и g++. Как вопрос задаете, так на него и
отвечают, а потом удивляетесь...

> Тут, конечно проблема в том, что NSS модули подгружаются динамически и
> сказать какие из них будут задействованы в момент запуска
> невозможно... Видимо действительно писать NSS-модули на С++ не самая
> лучшая идея.
>
> Тем не менее основной вопрос: нужен ли нам подобный модуль?
Я свое мнение по этому поводу уже выразил.

-- 
/ Alexander Bokovoy

Re: [devel] Управление группами пользователя

[Alexander Bokovoy]

2008/11/16 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> 16 ноября 2008 г. 18:54 пользователь Alexander Bokovoy
> <ab@altlinux.org> написал:
>> Посмотрите на Vala как на пример высокоуровневого языка, использующего
>> для выражения средства glib2. Vala написана на самой себе, так что
>> качестве примера довольно выразительна.
> Я не спорю, что вокруг glib2 можно построить высокоуровневую систему.
> Но это уже не С. Я полагаю, что вы не предлагаете нам написать модул
> на vala?
Нет, не предлагаю. А на Vala посмотрите. И с точки зрения "не C", и с
точки зрения высокоуровневости. Для понимания проблематики стоит также
посмотреть, например, на http://live.gnome.org/IteratorsAPI.

>> У меня тоже есть пожелание к переезду libstdc++ в /lib.
>>
>> Впрочем, от необдуманного написания кода это не спасает и "легче
>> выражаются языковыми конструкциями" вряди может служить в качестве
>> обоснования при написании низкоуровневых компонент, критичность
>> которых довольно высока.
> Легче выражается -> меньше шансов допустить ошибку.
Главная ошибка уже допущена: для решения задачи выбрано средство,
которое не соответствует уровню абстракции, на котором должен работать
модуль.

> По-моему инструмент надо выбирать не минимально достаточный для
> выполнения задачи, а наиболее удобный. Разве не так?
Нет. Должен выбираться соответствующий области применения инструмент.
В данном случае есть целый ряд требований к интерфейсу и побочным
эффектам от уже существующих приложений. Этот "монастырь" со своими
правилами, которые надо соблюдать, существует уже очень давно и выбор
средств тут ограничен именно требованиями совместимости. Не важно,
удобно лично Вам это средство или нет, важно, чтобы оно производило
результат, который удовлетворяет требованиям к таким модулям.

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

> Я утверждаю, что так как С++ поддерживает практически все конструкции
> С, но добавляет много новых, то он практически всегда удобнее.
> Единственный недостаток - шаблоны раздувают код, поэтому он может не
> подходить для встраиваемых систем. Для написания приложений для
> толстого desktop он практически всюду лучше С.
Не путайте Ваши приложения для десктопа и низкоуровневые компоненты
операционной системы.

>> Я не говорю уже про втягивание pthreads во
>> все приложения, которые могут быть и не готовы к этому. Один такой
>> пример плохой реализации внутри glibc мы уже видели
>> (http://samba.org/~tridge/junkcode/aio_uid.c).
> Да, на втягивании pthread в модуль (другой) мы уже наступали. В старом
> тулчейне gettext переставал работать)
Вот видите. Но тем не менее, тянете его за собой.

>> Главное, что я хотел продемонстрировать в этом обсуждении и что вы с
>> Дмитрием так пока и не поняли, что архитектурные и дизайнерские
>> решения не всегда принимаются на основании личных предпочтений. Прежде
>> всего необходимо думать о тех, кто использует разработанное. В случае
>> компонент ОС это прежде всего другие приложения и принцип "не навреди"
>> здесь играет главенствующую роль.
> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
> конструктивную критику, а не заявления, типа, "плох и все".
В данном конкретном случае C++ не является средством, которое
используется для написания низкоуровневых компонент, динамически
загружаемых во все приложения в системе из-за невозможности
проконтролировать все побочные эффекты, которые возникают при загрузке
и использовании такого сложного кода, как C++ stdlib.

-- 
/ Alexander Bokovoy

[devel] [JT] Re: Управление группами пользователя

[Michael Shigorin]

On Sun, Nov 16, 2008 at 07:39:08PM +0300, Dmitriy M. Maslennikov wrote:
> > Впрочем, от необдуманного написания кода это не спасает и
> > "легче выражаются языковыми конструкциями" вряди может
> > служить в качестве обоснования при написании низкоуровневых
> > компонент, критичность которых довольно высока.
> Легче выражается -> меньше шансов допустить ошибку.

Это не так.  Ошибки при таком отношении попросту перемещаются 
на другой уровень -- из ошибок реализации становятся ошибками
невладения инструментарием, дизайна, постановки задачи.

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

По-Вашему -- видимо.  Вообще -- нет, конечно.

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

Дмитрий, Вы явно имели возможность прочитать эти письма:
http://lists.linux.ru.net/pipermail/freeschool/2008-October/001298.html
http://lists.linux.ru.net/pipermail/freeschool/2008-October/001283.html

2 ldv: вот на этом месте уже и мне захотелось инструмент
для блэклистинга устанавливаемых в свои системы пакетов по
майнтейнеру.  Грустно, но факт.  Твой где-то взять можно?

> Согласен. Но все-таки, чем С++ плох? Хочется услышать именно
> конструктивную критику, а не заявления, типа, "плох и все".

Вы её не слышите, зачем просить ещё?

PS: за прибегание в devel@ прямиком с LOR и глупые нападки
с формулировками типа "приплёл" может иметь смысл недельный
readonly, как мне кажется :-/

PPS: а ещё страшно, что в базовой системе окажется код человека,
который и русским-то для объяснения позиции владеет на уровне
"Нам не нравиться. Все-равно не то." -- no offense :(
              ^       ^
-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] Re: Управление группами пользователя

[Dmitriy M. Maslennikov]

19 ноября 2008 г. 15:25 пользователь Michael Shigorin
<mike@osdn.org.ua> написал:
>> Я утверждаю, что так как С++ поддерживает практически все
>> конструкции С, но добавляет много новых, то он практически
>> всегда удобнее.  Единственный недостаток - шаблоны раздувают
>> код, поэтому он может не подходить для встраиваемых систем.
>> Для написания приложений для толстого desktop он практически
>> всюду лучше С.
>
> Дмитрий, Вы явно имели возможность прочитать эти письма:
> http://lists.linux.ru.net/pipermail/freeschool/2008-October/001298.html
> http://lists.linux.ru.net/pipermail/freeschool/2008-October/001283.html
Я согласен, что С++ ужасен, но его нечем заменить. Просто в этой нише
нет ни одного другого языка и все тут. А в тех, которые вы приводили
речь шла о С++ в качестве первого языка для обучения программированию.
И даже в этом качестве его успешно отстаивали его сторонники.

> 2 ldv: вот на этом месте уже и мне захотелось инструмент
> для блэклистинга устанавливаемых в свои системы пакетов по
> майнтейнеру.  Грустно, но факт.  Твой где-то взять можно?
Их так мало что вы это сможете сделать вручную. Только вот вы слишком
часто переходите на личности и offtop, что вам пора писать
предапреждение самому себе.

> PPS: а ещё страшно, что в базовой системе окажется код человека,
> который и русским-то для объяснения позиции владеет на уровне
> "Нам не нравиться. Все-равно не то." -- no offense :(
Как жаль, что в рассылке от альта придирки к стилю или ошибкам не
считаются злостным offtop'ом и за это не банят...

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] [JT] Re: Управление группами пользователя

[Денис Смирнов]

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

On Wed, Nov 19, 2008 at 03:38:03PM +0300, Dmitriy M. Maslennikov wrote:

DMM> Я согласен, что С++ ужасен, но его нечем заменить. Просто в этой нише
DMM> нет ни одного другого языка и все тут. А в тех, которые вы приводили
DMM> речь шла о С++ в качестве первого языка для обучения программированию.
DMM> И даже в этом качестве его успешно отстаивали его сторонники.

С++ есть чем заменить. C.
Который тоже ужасен. Но -- в linux-среде для системного программирования
это единственный приемлимый язык, не считая sh.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

19 ноября 2008 г. 16:35 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> On Wed, Nov 19, 2008 at 03:38:03PM +0300, Dmitriy M. Maslennikov wrote:
>
> DMM> Я согласен, что С++ ужасен, но его нечем заменить. Просто в этой нише
> DMM> нет ни одного другого языка и все тут. А в тех, которые вы приводили
> DMM> речь шла о С++ в качестве первого языка для обучения программированию.
> DMM> И даже в этом качестве его успешно отстаивали его сторонники.
>
> С++ есть чем заменить. C.
> Который тоже ужасен. Но -- в linux-среде для системного программирования
> это единственный приемлимый язык, не считая sh.
>

Я не согласен, если GLIBC разработана без учёта поддержки написания
модулей ни на чём, кроме С, то это ещё не означает, что С++ - это не
системный язык...

На этом языке написан apt, и ещё много чего будет написано...

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 16:44:01 19.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> На этом языке написан apt,

Типичный language misuse.

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Dmitriy M. Maslennikov]

19 ноября 2008 г. 16:44 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
> Twas brillig at 16:44:01 19.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:
>
>  ES> На этом языке написан apt,
>
> Типичный language misuse.
А вот yum, smart (менеджеры пакетов как и apt, первый для fedora) так
те вообще на python'е ))) Вот такой вот системный язык.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] [JT] Re: Управление группами пользователя

[Michael Shigorin]

On Wed, Nov 19, 2008 at 04:54:55PM +0300, Dmitriy M. Maslennikov wrote:
> >  ES> На этом языке написан apt,
> > Типичный language misuse.
> А вот yum, smart (менеджеры пакетов как и apt, первый для
> fedora) так те вообще на python'е )))

Это уже откровенный brain damage.  Ещё одним схожим примером
является bzr, который некоторые деятели умудряются сравнивать
с тем же git.  Иллюстрация тоже укладывается в общую картину.

> Вот такой вот системный язык.

Помнится, в младших классах и то аргументировали крепче,
чем "они убили Кенни -- давайте все убьём по Кенни"...

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

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 16:12:29 19.11.2008 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 MS> Ещё одним схожим примером является bzr, который некоторые деятели
 MS> умудряются сравнивать с тем же git.

И плавно свернул с системного софта на прикладной.

hg, который по скорости git'у уступает немного, а по консистентности
интерфейса - оставляет далеко позади. Так что language bashing
прекращай, тебе противопоказано, ибо у тебя явно питонофобия.

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Andrey Rahmatullin]

On Wed, Nov 19, 2008 at 08:15:14PM +0600, Mikhail Gusarov wrote:
> прекращай, тебе противопоказано, ибо у тебя явно питонофобия.
Точно.

Re: [devel] [JT] Управление группами пользователя

[Michael Shigorin]

On Wed, Nov 19, 2008 at 08:15:14PM +0600, Mikhail Gusarov wrote:
> > Ещё одним схожим примером является bzr, который некоторые
> > деятели умудряются сравнивать с тем же git.
> И плавно свернул с системного софта на прикладной.

IMHO apt -- полусистемный (в отличие от rpm),
поэтому скорее "продолжил сворачивание".

> hg, который по скорости git'у уступает немного, а по
> консистентности интерфейса - оставляет далеко позади.

На C++ тоже есть и хорошие разработки, и грамотные разработчики.
Речь, _к сожалению_, не о том.

> Так что language bashing прекращай, тебе противопоказано,
> ибо у тебя явно питонофобия.
  ^^^
А у тебя -- проблемы с логикой на фоне питонофилии.
Или "вы антипитонит" уже априорное клеймо? :)

-- 
Миша,
скорее питононедолюбливатель,
чем full scale питонофоб

Re: [devel] [JT] Управление группами пользователя

[Michael Shigorin]

On Wed, Nov 19, 2008 at 04:44:01PM +0300, Evgeny Sinelnikov wrote:
> Я не согласен, если GLIBC разработана без учёта поддержки
> написания модулей ни на чём, кроме С, то это ещё не означает,
> что С++ - это не системный язык...

Жень, можешь принять как данность.  C++ как системный язык бывает 
в других операционных окружениях -- посмотри Syllable или K42 вон.

Можешь послушать Линуса: http://kerneltrap.org/node/2067

Конечно, можно набивать и свои аутентичные шишки.

> На этом языке написан apt

Без него жить кое-как можно, вот без NSS -- совсем плохо.

> и ещё много чего будет написано...

Знаешь, к чему приводит такая логика?  В LTSP5 есть такая хрень,
ldm называется.  Запускается на тонком клиенте.  Так вот его
накропали на питоне.  Мало того, на вопрос "ну это ж был
прототип, правильно?" неглупый вообще-то человек сделал большие
глаза и сказал "да нет, а что?" (это уже переписав ldm2 на C).

Так вот из того, что с этим коррелирует: делали они этот ldm,
чтоб сессию заворачивать в ssh.  А пока делали, где-то что-то
с авторизацией не срослось и в итоге X-сервер на терминале
запускался с аргументом -ac.  Бишь без авторизации вааще.
Кстати, в таком виде они это клали в Edubuntu два года.

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

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

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

Re: [devel] [JT] Re: Управление группами пользователя

[Alexey I. Froloff]

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

* Evgeny Sinelnikov <sin@> [081119 17:03]:
> На этом языке написан apt,
Вы его внутри видели?

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

19 ноября 2008 г. 17:22 пользователь Alexey I. Froloff
<raorn@altlinux.ru> написал:
> * Evgeny Sinelnikov <sin@> [081119 17:03]:
>> На этом языке написан apt,
> Вы его внутри видели?
>

Криво написать можно на чём угодно... Хоть на C, хоть на bash...
Вопрос в том, что C++, как язык, не мешает жить важному системному
компоненту... Я бы посмотрел ещё, как тоже самое на C реализовали...

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 17:25:29 19.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> Вопрос в том, что C++, как язык, не мешает жить важному системному
 ES> компоненту...

Мешает. В полу-embedded, скажем.

 ES> Я бы посмотрел ещё, как тоже самое на C реализовали...

Ровно так же, как на C++. Выкинув по дороге несколько неиспользуемых в
APT уровней абстракции, которые сделали "щоб було".

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Alexey I. Froloff]

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

* Evgeny Sinelnikov <sin@> [081119 17:36]:
> > * Evgeny Sinelnikov <sin@> [081119 17:03]:
> >> На этом языке написан apt,
> > Вы его внутри видели?
> Криво написать можно на чём угодно... Хоть на C, хоть на bash...
Вы понимаете, что сами себе противоречите?

> Вопрос в том, что C++, как язык, не мешает жить важному системному
> компоненту...
Зато мешает тем, кто с этим компонентом пытается что-то сделать.
Вот я прямщас ковыряюсь внутри aptitude (и apt) и тихонько матерюсь.

> Я бы посмотрел ещё, как тоже самое на C реализовали...
Я тоже.  С превеликим удовольствием.  Вот только некоторые
"системные программисты" считают себя большими специалистами в
области "мультипарадигмальных языков" и
"об'ектно-ориентированного программирования", переписывают
shell-скрипты как попало на том, что они в данный момент
безуспешно пытаются изучить, а потом весь остаток жизни проекта
заделывают архитектурные недостатки кривыми костылями вместо
того, чтобы признать, что они сделали полное г-но и переписать
всё по человечески.

Извините, наболело.

/me тяжело вздохнул и пошёл дальше протаскивать передачу левого
об'екта через 25 функций в пяти разных классах.

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

19 ноября 2008 г. 18:27 пользователь Alexey I. Froloff
<raorn@altlinux.ru> написал:
> * Evgeny Sinelnikov <sin@> [081119 17:36]:
>> > * Evgeny Sinelnikov <sin@> [081119 17:03]:
>> >> На этом языке написан apt,
>> > Вы его внутри видели?
>> Криво написать можно на чём угодно... Хоть на C, хоть на bash...
> Вы понимаете, что сами себе противоречите?
>

Нет, у себя противоречий не выявляю... Я уверен, что множество
приложений написанных на C испытывают те же, если не бОльшие, проблемы
архитектурного плана, что и приложения, написанные на С++... К языку
это никакого отношения не имеет... А поскольку С++ построен на
обобщении отдельных образцов проектирования, то у него с этим проблем
даже по-меньше, чем у C. Вот только нивелируется это определённой
сложностью, овладеть которой довольно не просто....

>> Вопрос в том, что C++, как язык, не мешает жить важному системному
>> компоненту...
> Зато мешает тем, кто с этим компонентом пытается что-то сделать.
> Вот я прямщас ковыряюсь внутри aptitude (и apt) и тихонько матерюсь.
>
>> Я бы посмотрел ещё, как тоже самое на C реализовали...
> Я тоже.  С превеликим удовольствием.  Вот только некоторые
> "системные программисты" считают себя большими специалистами в
> области "мультипарадигмальных языков" и
> "об'ектно-ориентированного программирования", переписывают
> shell-скрипты как попало на том, что они в данный момент
> безуспешно пытаются изучить, а потом весь остаток жизни проекта
> заделывают архитектурные недостатки кривыми костылями вместо
> того, чтобы признать, что они сделали полное г-но и переписать
> всё по человечески.

Честно говоря, переписать на другом языке по силу обычно только другим
людям и, желательно, с другой архитектурой :) Почему же всё до сих пор
не переписано, если так требуется?

> Извините, наболело.
>
> /me тяжело вздохнул и пошёл дальше протаскивать передачу левого
> об'екта через 25 функций в пяти разных классах.
>

Пробрасывание через 25 функций объекта класса или экземпляра
структуры, на который ссылаются ещё из 5 структур - не всё ли равно
какая разница?



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Денис Смирнов]

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

On Wed, Nov 19, 2008 at 04:44:01PM +0300, Evgeny Sinelnikov wrote:

>> С++ есть чем заменить. C.
>> Который тоже ужасен. Но -- в linux-среде для системного программирования
>> это единственный приемлимый язык, не считая sh.
ES> Я не согласен, если GLIBC разработана без учёта поддержки написания
ES> модулей ни на чём, кроме С, то это ещё не означает, что С++ - это не
ES> системный язык...
ES> На этом языке написан apt, и ещё много чего будет написано...

В случае с Linux, C++ -- это не язык для системного программирования.

Я Вас понимаю. Мне тоже часто очень хочется использовать отдельные
возможности C++. Но, увы, языка для системного программирования сейчас
кроме C -- нет :(

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

19 ноября 2008 г. 20:57 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> On Wed, Nov 19, 2008 at 04:44:01PM +0300, Evgeny Sinelnikov wrote:
>
>>> С++ есть чем заменить. C.
>>> Который тоже ужасен. Но -- в linux-среде для системного программирования
>>> это единственный приемлимый язык, не считая sh.
> ES> Я не согласен, если GLIBC разработана без учёта поддержки написания
> ES> модулей ни на чём, кроме С, то это ещё не означает, что С++ - это не
> ES> системный язык...
> ES> На этом языке написан apt, и ещё много чего будет написано...
>
> В случае с Linux, C++ -- это не язык для системного программирования.
>

Вы ошибаетесь...

> Я Вас понимаю. Мне тоже часто очень хочется использовать отдельные
> возможности C++. Но, увы, языка для системного программирования сейчас
> кроме C -- нет :(
>

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

Никто не мешает писать системные сервисы на С++ под Linux. Чем же не
системное программирование?

Наличие системных ограничений, связанных с особенностями компоновки в
GLIBC, означает только то, что не стоит писать модули NSS для GLIBC на
C++... То есть писать-то можно и работать они будут... Только вот
могут быть конфигурации, в которых они могут не заработать, поэтому в
перспективе не стоит... Но вот какое дело, любые приложения способны
работать только определённых условиях... Вопрос в том насколько трудно
эти условия поддерживать...

Итого на C++, в текущих реализациях ядра, не стоит писать модули ядра
и, в текущей реализации GLIBC, не стоит писать модули для NSS. Этими
задачами системное программирование не ограничивается...


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Денис Смирнов]

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

On Thu, Nov 20, 2008 at 12:21:51AM +0300, Evgeny Sinelnikov wrote:

ES> Итого на C++, в текущих реализациях ядра, не стоит писать модули ядра
ES> и, в текущей реализации GLIBC, не стоит писать модули для NSS. Этими
ES> задачами системное программирование не ограничивается...

А также не стоит писать что-либо, что запускается до монтирования /usr.
Конечно не ограничивается. Но в данной конкретной задаче выбор C++ был
разумен только для написания концепта.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

20 ноября 2008 г. 0:24 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> On Thu, Nov 20, 2008 at 12:21:51AM +0300, Evgeny Sinelnikov wrote:
>
> ES> Итого на C++, в текущих реализациях ядра, не стоит писать модули ядра
> ES> и, в текущей реализации GLIBC, не стоит писать модули для NSS. Этими
> ES> задачами системное программирование не ограничивается...
>
> А также не стоит писать что-либо, что запускается до монтирования /usr.

Я думаю, что ничто не мешает переместить libstdc++ в /lib, чтобы
обойти это ограничение...

> Конечно не ограничивается. Но в данной конкретной задаче выбор C++ был
> разумен только для написания концепта.
>

В данной задаче, да...



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 00:21:51 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> Никто не мешает писать системные сервисы на С++ под Linux. Чем же
 ES> не системное программирование?

Тогда Haskell - это тоже язык системного программирования. Благо, выхлоп
из-под ghc6 ничего лишнего, кроме C-библиотек, которыми пользуется
приложение, не требует.

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

20 ноября 2008 г. 0:26 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
> Twas brillig at 00:21:51 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:
>
>  ES> Никто не мешает писать системные сервисы на С++ под Linux. Чем же
>  ES> не системное программирование?
>
> Тогда Haskell - это тоже язык системного программирования. Благо, выхлоп
> из-под ghc6 ничего лишнего, кроме C-библиотек, которыми пользуется
> приложение, не требует.
>

По моему, вы сравниваете уже не сравнимое... C++ совместим с C на
уровне devel-пакетов... Из чего следует, что ему не требуются костыли
в виде связок...

Вообще не особо стремлюсь доказывать очевидные вещи. Но когда вижу
несуразные сравнения, крайне удивляюсь... В данном же случае у меня
складывается впечатление, что личные предпочтения навязываются путём
давления авторитетов... К сожалению, здесь наши предпочтения
расходятся... :)


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 00:39:11 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> По моему, вы сравниваете уже не сравнимое...

Покажите, почему несравнимы?

 ES> C++ совместим с C на уровне devel-пакетов...

Не совместим. extern "C", #define class class_, и т.д.

 ES> Из чего следует, что ему не требуются костыли в виде связок...

Связки для Haskell занимаются ровно тем, что в C++ делается либо неявно
и несепарабельно (превед!), либо отдельной связкой, называемой обёрткой:
преодолением разницы в подоходах языков к управлению памятью и ресурсами
и обработке ошибок.

Я уж не говорю, что для Haskell есть c2hs, а для C++ обёртки писать надо
руками.

 ES> Вообще не особо стремлюсь доказывать очевидные вещи.

Здесь наши очевидности расходятся.

 ES> Но когда вижу несуразные сравнения, крайне удивляюсь...

Покажите несуразное сравнение. Я пока вижу только суразные.

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

20 ноября 2008 г. 0:49 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
> Twas brillig at 00:39:11 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:
>
>  ES> По моему, вы сравниваете уже не сравнимое...
>
> Покажите, почему несравнимы?

К сожалению, я не знаком с Haskell настолько, чтобы дать вам
развёрнутый ответ. Но я полагаю, что Haskell запускает для своих
приложений внутренюю среду, позволяющую реализовать его
функциональность на компьютерах, аппаратно её не поддерживающих. С++
же настолько же близок к железу, что и C... В этом они с Haskel не
сравнимы..

>
>  ES> C++ совместим с C на уровне devel-пакетов...
>
> Не совместим. extern "C", #define class class_, и т.д.
>

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

>  ES> Из чего следует, что ему не требуются костыли в виде связок...
>
> Связки для Haskell занимаются ровно тем, что в C++ делается либо неявно
> и несепарабельно (превед!), либо отдельной связкой, называемой обёрткой:
> преодолением разницы в подоходах языков к управлению памятью и ресурсами
> и обработке ошибок.
>

Я не совсем понял, о чём здесь идёт речь, но вот это, например, явная связка:
http://www.cse.unsw.edu/~chak/haskell/gtk/
http://haskell.org/gtk2hs/

Кстати, GTK как раз и содержит в заголовочных файлах ряд
вышеозначенных несовместимостей, которые, как я полагаю, сделаны по
причине явных предпочтений авторов в пользу С, по сравнению с C++.

> Я уж не говорю, что для Haskell есть c2hs, а для C++ обёртки писать надо
> руками.
>

По моему вы недооцениваете порядок сложности того, что предлагаете...
Иначе почему концепция, которую взяла за основу в c2hs близка к
мёртвому проекту "A GTK+ Binding for Haskell", который был сменён
gtk2hs? А ведь в gtk2hs я вижу кучу ручного кода....

>  ES> Вообще не особо стремлюсь доказывать очевидные вещи.
>
> Здесь наши очевидности расходятся.
>

С некоторого момента очевидности уже недоказуемы - эта граница
называется мировоззренческой позицией.

>  ES> Но когда вижу несуразные сравнения, крайне удивляюсь...
>
> Покажите несуразное сравнение. Я пока вижу только суразные.
>

"Тогда Haskell - это тоже язык системного программирования"


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 11:53:05 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> Но я полагаю, что Haskell запускает для своих приложений внутренюю
 ES> среду, позволяющую реализовать его функциональность на компьютерах,
 ES> аппаратно её не поддерживающих.  С++ же настолько же близок к
 ES> железу, что и C... В этом они с Haskel не сравнимы..

Как это отражается на функционировании? Всё остальное - среда, не среда
- полнейший bullshit.

 >> Не совместим. extern "C", #define class class_, и т.д.

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

Кто будет оборачивать коды ошибки в исключения? Кто будет реализовывать
RAII? Вы не понимаете, что C++-ный код враппера тупо будет размазан по
всей программе тонким слоем? Причём в каждой программе - свой код.

 >> Связки для Haskell занимаются ровно тем, что в C++ делается либо
 >> неявно и несепарабельно (превед!), либо отдельной связкой,
 >> называемой обёрткой: преодолением разницы в подоходах языков к
 >> управлению памятью и ресурсами и обработке ошибок.

 ES> Я не совсем понял, о чём здесь идёт речь,

А вы подумайте, подумайте. Ключевые слова: разница в семантике
управления памятью и обработке ошибок, RAII.

 ES> но вот это, например, явная связка:
 ES> http://www.cse.unsw.edu/~chak/haskell/gtk/
 ES> http://haskell.org/gtk2hs/

gtkmm.

 ES> Кстати, GTK как раз и содержит в заголовочных файлах ряд
 ES> вышеозначенных несовместимостей, которые, как я полагаю, сделаны по
 ES> причине явных предпочтений авторов в пользу С, по сравнению с C++.

О да. А также он содержит ряд вышенеозначенных несовместимостей,
мешающих без ручного кода сделать Haskell-биндинг. Как я полагаю,
сделаны они по причине явных предпочтений авторов в пользу C по
сравнению с Haskell. Могли бы потрудиться и написать попроще, чтобы
биндинги генерить можно было. Впрочем, для C++ всё равно биндинг нужен.

 ES> По моему вы недооцениваете порядок сложности того, что
 ES> предлагаете...  Иначе почему концепция, которую взяла за основу в
 ES> c2hs близка к мёртвому проекту "A GTK+ Binding for Haskell",
 ES> который был сменён gtk2hs?

Потому, что GTK+ Binding for Haskell забросили авторы? Это не имеет ни
малейшего отношения к делу.

 ES> А ведь в gtk2hs я вижу кучу ручного кода....

В gtkmm я тоже вижу кучу ручного кода.

gtk2hs - 1.1M
gtkmm-1.2.10 - 704k

Где разница?

 >> Здесь наши очевидности расходятся.

 ES> С некоторого момента очевидности уже недоказуемы - эта граница
 ES> называется мировоззренческой позицией.

Нет уж, извините. Я требую вполне конкретных вещей, а вы не можете их
предоставить.

Пока что вы

a) сказали, что "Haskell, очевидно, не язык системного
программирования". Я утверждаю с той же степенью авторитетности, что
"C++, очевидно, не язык системного программирования"

b) Предоставили некий набор правил, по которым определяется
"системность" языка, и не смогли опровергнуть, что Haskell под них не
попадает.

 >> Покажите несуразное сравнение. Я пока вижу только суразные.

 ES> "Тогда Haskell - это тоже язык системного программирования"

Тогда опровергните! Не "мне кажется" или "я считаю", а фактами. Раз уж
вы выдвинули свою теорию о классификации языков - она должна выдержать
первое же испытание.

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

20 ноября 2008 г. 12:31 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
> Twas brillig at 11:53:05 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:
>
>  ES> Но я полагаю, что Haskell запускает для своих приложений внутренюю
>  ES> среду, позволяющую реализовать его функциональность на компьютерах,
>  ES> аппаратно её не поддерживающих.  С++ же настолько же близок к
>  ES> железу, что и C... В этом они с Haskel не сравнимы..
>
> Как это отражается на функционировании? Всё остальное - среда, не среда
> - полнейший bullshit.

Я не знаю что такое bullshit... Но а вот обратиться к нужному адресу в
памяти я на Haskell вряд ли смогу так запросто... Я уже сказал, что
"не знаком с Haskell настолько, чтобы дать вам развёрнутый ответ"... А
соответственно допускаю, что в нём можно многое, но в нём, в отличии
от С++, вряд ли можно всё что, что можно в C...

>
>  >> Не совместим. extern "C", #define class class_, и т.д.
>
>  ES> Да, есть такой набор ограничений, за их исключением совместимость
>  ES> практически полная... Я бы сказал, что на практике эти ограничения
>  ES> встречаются тогда когда, ими пренебрегают. Думаю, что в ряде
>  ES> случаев, даже намеренно...
>
> Кто будет оборачивать коды ошибки в исключения? Кто будет реализовывать

Сишный код не кидает исключений...

> RAII? Вы не понимаете, что C++-ный код враппера тупо будет размазан по

То что нужно от RAII в С всё равно пишут руками, так что эта часть
только упрощает использование С библиотек в С++...

> всей программе тонким слоем? Причём в каждой программе - свой код.
>

Не в каждой, а только в тех, которые будут использовать сишные либы
напрямую, пропустив C++ варианты в целях некой оптимизации или
отсутствия  необходимых C++ вариантов...

>  >> Связки для Haskell занимаются ровно тем, что в C++ делается либо
>  >> неявно и несепарабельно (превед!), либо отдельной связкой,
>  >> называемой обёрткой: преодолением разницы в подоходах языков к
>  >> управлению памятью и ресурсами и обработке ошибок.
>
>  ES> Я не совсем понял, о чём здесь идёт речь,
>
> А вы подумайте, подумайте. Ключевые слова: разница в семантике
> управления памятью и обработке ошибок, RAII.
>

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

>  ES> но вот это, например, явная связка:
>  ES> http://www.cse.unsw.edu/~chak/haskell/gtk/
>  ES> http://haskell.org/gtk2hs/
>
> gtkmm.
>

Для С++ есть QT, а так... да верно, если всё писать на С, то со
связками те же проблемы... Но писать их проще, и пишутся они
прозрачно, через встроенные средства языка... В C++ не требуется для
работы сначала сделать связку в виде библиотеки, а потом начать
работать...

>  ES> Кстати, GTK как раз и содержит в заголовочных файлах ряд
>  ES> вышеозначенных несовместимостей, которые, как я полагаю, сделаны по
>  ES> причине явных предпочтений авторов в пользу С, по сравнению с C++.
>
> О да. А также он содержит ряд вышенеозначенных несовместимостей,
> мешающих без ручного кода сделать Haskell-биндинг. Как я полагаю,
> сделаны они по причине явных предпочтений авторов в пользу C по
> сравнению с Haskell. Могли бы потрудиться и написать попроще, чтобы
> биндинги генерить можно было. Впрочем, для C++ всё равно биндинг нужен.
>

согласен, GTK - ужасен... :)

>  ES> По моему вы недооцениваете порядок сложности того, что
>  ES> предлагаете...  Иначе почему концепция, которую взяла за основу в
>  ES> c2hs близка к мёртвому проекту "A GTK+ Binding for Haskell",
>  ES> который был сменён gtk2hs?
>
> Потому, что GTK+ Binding for Haskell забросили авторы? Это не имеет ни
> малейшего отношения к делу.
>

Я только спросил... раз не имеет - значит так уж сложилось... но
причины-то были...

>  ES> А ведь в gtk2hs я вижу кучу ручного кода....
>
> В gtkmm я тоже вижу кучу ручного кода.
>
> gtk2hs - 1.1M
> gtkmm-1.2.10 - 704k
>
> Где разница?
>

Разница в том, что в С++ GTK можно вызывать и без связки, а в Haskell - нет.

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

Если вы требуете признания того, что Haskell такой же "системный
язык", что и C++, то я скорее склонен согласиться, чем спорить :)

Но, к сожалению, вести речь о его применимости для многих задач я уже
не готов... А поскольку я не готов его применить, то "системным"
считать не могу :) Далее мы, скорее всего, снова упрёмся в личные
предпочтения...

> Пока что вы
>
> a) сказали, что "Haskell, очевидно, не язык системного
> программирования". Я утверждаю с той же степенью авторитетности, что
> "C++, очевидно, не язык системного программирования"
>

Я сказал ранее, что не вижу ограничений для C++ кроме тех, что на его
применение не рассчитаны модули ядра и NSS модули... Таких ограничений
для Haskell я вижу гораздо больше...

> b) Предоставили некий набор правил, по которым определяется
> "системность" языка, и не смогли опровергнуть, что Haskell под них не
> попадает.
>

Хм.. набор, определяющий "системность языка"? Я его и не пытался
предоставить...

>  >> Покажите несуразное сравнение. Я пока вижу только суразные.
>
>  ES> "Тогда Haskell - это тоже язык системного программирования"
>
> Тогда опровергните! Не "мне кажется" или "я считаю", а фактами. Раз уж
> вы выдвинули свою теорию о классификации языков - она должна выдержать
> первое же испытание.
>

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

Вы что-то путаете по поводу "моей теории" классификации языков - я её
не выдвигал. Я высказал мнение о том, что сравнимать С++ и Haskell,
против C и C++, несуразно...

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 16:21:36 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> Я не знаю что такое bullshit... Но а вот обратиться к нужному
 ES> адресу в памяти я на Haskell вряд ли смогу так запросто...

Это дело ядра, вообще-то. Но заворачивание void* тривиально.

 >> Кто будет оборачивать коды ошибки в исключения? Кто будет
 >> реализовывать

 ES> Сишный код не кидает исключений...

Зато кидает C++-ный. Попробуйте осознать, что это означает.

 >> RAII? Вы не понимаете, что C++-ный код враппера тупо будет размазан по

 ES> То что нужно от RAII в С всё равно пишут руками, так что эта часть
 ES> только упрощает использование С библиотек в С++...

C++-ный код кидает исключения. В C++ нет ключевого слова finally в блоке
try/catch. Подумайте, почему из этого автоматически следует
_необходимость_ иметь врапперы для всего нетривиального (управляющего
ресурсами любого рода) C-кода, используемого из C++.

 ES> Не в каждой, а только в тех, которые будут использовать сишные либы
 ES> напрямую, пропустив C++ варианты в целях некой оптимизации или
 ES> отсутствия необходимых C++ вариантов...

Сравните с "не в каждой, а только в тех, которые будут использовать
сишные либы напрямую, пропустив Haskell-варианты в целяз некой
оптимизации или отсутствия необходимых Haskell-вариантов".

 >> А вы подумайте, подумайте. Ключевые слова: разница в семантике
 >> управления памятью и обработке ошибок, RAII.

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

Это не аргумент. Врапперы "по ходу дела" в Haskell делаются ровно так
же. Какая разница, что они лежат в отдельном файле?

 ES> Для С++ есть QT, а так... да верно, если всё писать на С, то со
 ES> связками те же проблемы... Но писать их проще, и пишутся они
 ES> прозрачно, через встроенные средства языка...

Это вам "прозрачно", потому что вы на C++ пишете. А разработчику на
Haskell "прозрачно" использовать встроенные средства языка, типа FFI,
или обёртки, типа c2hs.

 ES> В C++ не требуется для работы сначала сделать связку в виде
 ES> библиотеки, а потом начать работать...

Если есть желание получить неотлаживаемый memory- или resource-лик, то
да. Это замечательное свойство для языка системного программирования.

 ES> Разница в том, что в С++ GTK можно вызывать и без связки, а в Haskell - нет.

Нельзя. См. выше про RAII, исключения и отсутствие finally.

 ES> Если вы требуете признания того, что Haskell такой же "системный
 ES> язык", что и C++, то я скорее склонен согласиться, чем спорить :)

Вот! Да, ровно этого я и добивался. А теперь вопрос, на который вы
отвечаете ниже: а с вашей точки зрения Haskell и правда язык системного
программирования?

 ES> Но, к сожалению, вести речь о его применимости для многих задач я
 ES> уже не готов... А поскольку я не готов его применить, то
 ES> "системным" считать не могу :) Далее мы, скорее всего, снова
 ES> упрёмся в личные предпочтения...

Т.е. язык системного программирования оказался совершенно субъективным
делом, и ваше высказывание, что C++ - язык системного программирования,
подкреплено лишь вашим авторитетом, ибо существенной разницы между C++ и
Haskell, следуя вашей логике доказательства, мы не нашли, а Haskell вы
таковым не считаете.

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

20 ноября 2008 г. 16:36 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
> Twas brillig at 16:21:36 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:
>
>  ES> Я не знаю что такое bullshit... Но а вот обратиться к нужному
>  ES> адресу в памяти я на Haskell вряд ли смогу так запросто...
>
> Это дело ядра, вообще-то. Но заворачивание void* тривиально.
>

В Haskell это доступно на уровне языка? Или опять тривиальное
заворачивание через связку?

>  >> Кто будет оборачивать коды ошибки в исключения? Кто будет
>  >> реализовывать
>
>  ES> Сишный код не кидает исключений...
>
> Зато кидает C++-ный. Попробуйте осознать, что это означает.
>
>  >> RAII? Вы не понимаете, что C++-ный код враппера тупо будет размазан по
>
>  ES> То что нужно от RAII в С всё равно пишут руками, так что эта часть
>  ES> только упрощает использование С библиотек в С++...
>
> C++-ный код кидает исключения. В C++ нет ключевого слова finally в блоке
> try/catch. Подумайте, почему из этого автоматически следует
> _необходимость_ иметь врапперы для всего нетривиального (управляющего
> ресурсами любого рода) C-кода, используемого из C++.
>

finally обходится через RAII. Кроме того, side-эффекты сишных
библиотек, в ряде случаев, не способны отслеживать даже сами сишные
приложения. Так что не стоит столь педантично подходить к этому
вопросу... Заворачивать нужно равно то, что требуется... А если
уходить в глубокую рекурсию с перебором всех возможных вариантов, то
враппер получится невразумительный... Любые задачи в общем случае
решаются сложнее, чем в частных.

>  ES> Не в каждой, а только в тех, которые будут использовать сишные либы
>  ES> напрямую, пропустив C++ варианты в целях некой оптимизации или
>  ES> отсутствия необходимых C++ вариантов...
>
> Сравните с "не в каждой, а только в тех, которые будут использовать
> сишные либы напрямую, пропустив Haskell-варианты в целяз некой
> оптимизации или отсутствия необходимых Haskell-вариантов".
>
>  >> А вы подумайте, подумайте. Ключевые слова: разница в семантике
>  >> управления памятью и обработке ошибок, RAII.
>
>  ES> Ну, тут пожалуй соглашусь, только в том, что связки могут быть не
>  ES> простыми... Но ведь дело в том, что для частных случаев в С++
>  ES> связки делаются в самом коде, и при этом не требуется усилий чтобы
>  ES> получить доступ к вызовам С-шных библиотек...
>
> Это не аргумент. Врапперы "по ходу дела" в Haskell делаются ровно так
> же. Какая разница, что они лежат в отдельном файле?
>

При увеличении сущностей увеличивается сложность... Но может быть всё
не так и плохо...

>  ES> Для С++ есть QT, а так... да верно, если всё писать на С, то со
>  ES> связками те же проблемы... Но писать их проще, и пишутся они
>  ES> прозрачно, через встроенные средства языка...
>
> Это вам "прозрачно", потому что вы на C++ пишете. А разработчику на
> Haskell "прозрачно" использовать встроенные средства языка, типа FFI,
> или обёртки, типа c2hs.
>

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

>  ES> В C++ не требуется для работы сначала сделать связку в виде
>  ES> библиотеки, а потом начать работать...
>
> Если есть желание получить неотлаживаемый memory- или resource-лик, то
> да. Это замечательное свойство для языка системного программирования.
>
>  ES> Разница в том, что в С++ GTK можно вызывать и без связки, а в Haskell - нет.
>
> Нельзя. См. выше про RAII, исключения и отсутствие finally.

Можно-можно... Работать будет криво, но это вопрос второй... У C++
есть более удобные альтернативы, так что вопрос о связках во многих
случаях просто не стоит... Для Haskel же вопрос связок вещь
необходимая ибо библиотек не так много, что и сужает сферу его
применимости.

>
>  ES> Если вы требуете признания того, что Haskell такой же "системный
>  ES> язык", что и C++, то я скорее склонен согласиться, чем спорить :)
>
> Вот! Да, ровно этого я и добивался. А теперь вопрос, на который вы
> отвечаете ниже: а с вашей точки зрения Haskell и правда язык системного
> программирования?
>

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

>  ES> Но, к сожалению, вести речь о его применимости для многих задач я
>  ES> уже не готов... А поскольку я не готов его применить, то
>  ES> "системным" считать не могу :) Далее мы, скорее всего, снова
>  ES> упрёмся в личные предпочтения...
>
> Т.е. язык системного программирования оказался совершенно субъективным
> делом, и ваше высказывание, что C++ - язык системного программирования,
> подкреплено лишь вашим авторитетом, ибо существенной разницы между C++ и
> Haskell, следуя вашей логике доказательства, мы не нашли, а Haskell вы
> таковым не считаете.
>

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

Я вряд ли выберу Haskell для какой-нибудь системной задачи... И, я
думаю, вряд ли найдётся много добровольцев использовать его в
системных задачах. А вот C++ может использоваться (без RTTI и STDLIB)
даже во встроенных системах...

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 18:48:05 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

Меня попросили прекратить флейм, так что отвечу кратко: вы во многом
ошибаетесь :)

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Alexey I. Froloff]

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

* Evgeny Sinelnikov <sin@> [081120 16:29]:
> Но а вот обратиться к нужному адресу в памяти я на Haskell вряд
> ли смогу так запросто...
О господи.  У меня будет просьба личного характера - не пишите
больше ничего.  Никогда.  Ни на C++, ни на Haskel, ни на каком
другом языке вне зависимости от того, можно там обратиться к
произвольному адресу памяти или нельзя.

-- 
Regards,
Sir Raorn.

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

Re: [devel] [JT] Re: Управление группами пользователя

[Evgeny Sinelnikov]

20 ноября 2008 г. 18:44 пользователь Alexey I. Froloff
<raorn@altlinux.ru> написал:
> * Evgeny Sinelnikov <sin@> [081120 16:29]:
>> Но а вот обратиться к нужному адресу в памяти я на Haskell вряд
>> ли смогу так запросто...
> О господи.  У меня будет просьба личного характера - не пишите
> больше ничего.  Никогда.  Ни на C++, ни на Haskel, ни на каком
> другом языке вне зависимости от того, можно там обратиться к
> произвольному адресу памяти или нельзя.
Странный у вас сарказм... Видимо потому, что вы считаете, что если
модули ядра Linux не стоит писать на С++ в силу Legacy, инертности и
того опыта, который был у Линуса c C++ в 1992 году (тогда и стандарта
текущего не было), то на нём вообще ничего системного писать нельзя...

PS: раз флейм нужно прекращать, то обещаю, по крайней мере, в эту
дискуссию больше ничего не писать.... :)

-- 
Sin (Sinelnikov Evgeny)

Re: [devel] [JT] Re: Управление группами пользователя

[Damir Shayhutdinov]

> PS: раз флейм нужно прекращать, то обещаю, по крайней мере, в эту
> дискуссию больше ничего не писать.... :)

Можно пойти в курилку, разбавить программистскими религиозными войнами
религиозные религиозные войны. ;)

Re: [devel] [JT] Re: Управление группами пользователя

[Andrey Rahmatullin]

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

On Thu, Nov 20, 2008 at 12:39:11AM +0300, Evgeny Sinelnikov wrote:
> По моему, вы сравниваете уже не сравнимое... C++ совместим с C на
> уровне devel-пакетов... Из чего следует, что ему не требуются костыли
> в виде связок...
http://yosefk.com/c++fqa/mixing.html

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Я, разумеется, не имею ничего против LRN-BTS, однако базу данных для
нашей BTS по соображениям безопасности я бы хотел держать в другом месте.
		-- ldv in devel@

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

Re: [devel] [JT] Re: Управление группами пользователя

[Mikhail Gusarov]

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

Twas brillig at 03:26:29 20.11.2008 UTC+06 when dottedmag@altlinux.org did gyre and gimble:

 MG> Тогда Haskell - это тоже язык системного программирования. Благо,
 MG> выхлоп из-под ghc6 ничего лишнего, кроме C-библиотек, которыми
 MG> пользуется приложение, не требует.

Кстати, ситуация с Haskell и C++ похожа до глупости: и тому, и тому
нужно по одной библиотеке из /usr/lib (libgmp и libstdc++
соответственно).

Правда, libgmp на порядок попроще будет.

-- 

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

Re: [devel] [JT] Re: Управление группами пользователя

[Alexey I. Froloff]

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

* Michael Shigorin <mike@> [081119 15:40]:
> 2 ldv: вот на этом месте уже и мне захотелось инструмент
> для блэклистинга устанавливаемых в свои системы пакетов по
> майнтейнеру.  Грустно, но факт.  Твой где-то взять можно?
aptitude (сюрпрайз, сюрпрайз!)

-- 
Regards,
Sir Raorn.

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

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

16 ноября 2008 г. 17:40 пользователь Stanislav Ievlev
<inger@altlinux.org> написал:
> Я так понимаю C++ использовался потому что там можно строить более удобные структуры данных?
Именно так.

> Попробуйте посмотреть на хеш-таблицы в glibc и на glib2. Возможно понравится ;)
Нам не нравиться. Все-равно не то.

> Последняя библиотека с некоторого времени лежит в /lib ибо её использует syslog-ng. Да и вообще
> это хороший сборник 'велосипедов', хорошо восполняющий асектизм стандартного C.
Может и стандартную библиотеку С++ туда? По-моему язык это уже давно
заслужил. От остальных зависимостей на boost мы избавимся.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Led]

On Sunday, 16 November 2008 17:38:32 Dmitriy M. Maslennikov wrote:
> > Последняя библиотека с некоторого времени лежит в /lib ибо её использует
> > syslog-ng. Да и вообще это хороший сборник 'велосипедов', хорошо
> > восполняющий асектизм стандартного C.
>
> Может и стандартную библиотеку С++ туда? По-моему язык это уже давно
> заслужил.

А по-моему - нет. И, скорее всего, никогда не заслужит.

-- 
Led

Re: [devel] Управление группами пользователя

[Dmitry V. Levin]

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

On Sat, Nov 15, 2008 at 09:29:42AM +0300, Dmitriy M. Maslennikov wrote:
> 15 ноября 2008 г. 1:00 пользователь Денис Смирнов
[...]
> > Да, мне этот инструмент кажется полезным но думаю потребуется помочь ldv@
> > чтобы подобное задействовать -- все-таки это системообразующий пакет.
> Так вот и ждем его мнения.

Я обязательно посмотрю и выскажу своё мнение.


-- 
ldv

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

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 22:07:41 Stanislav Ievlev wrote:
> On Fri, Nov 14, 2008 at 10:01:13PM +0200, Led wrote:
> > On Friday, 14 November 2008 21:56:59 Dmitriy M. Maslennikov wrote:
> > > 14 ноября 2008 г. 22:55 пользователь Led <ledest@gmail.com> написал:
> > > > Пожалуйста, не надо это на Desktop.
> > >
> > > А можете пояснить почему? Мне кажется, что строка c default_groups в
> > > alterator-users выглядит, как весьма негибкое и костыльное решение.
> >
> > Потому, что если не нравится модуль альтератора, нужно улучшать его
> > (хотя, в случае с альтератором, это моветон
>
> г-н led@, с этого места пожалуйста поподробнее.

О чём? О том, что если модуль альтератора, если он чем-то не устраивает, 
неплохо бы улучшить, чтобы он устраивал?


-- 
Led

[devel] [JT] alterator (was: Управление группами пользователя)

[Michael Shigorin]

On Fri, Nov 14, 2008 at 11:07:41PM +0300, Stanislav Ievlev wrote:
> > Потому, что если не нравится модуль альтератора, нужно
> > улучшать его (хотя, в случае с альтератором, это моветон
> г-н led@, с этого места пожалуйста поподробнее.

Думаю, Саша здесь насмотрелся на то, как альтератор ускользает
из-под рук пытающихся что-либо исправить, а также пострадал от
разломанного переездом на hal only модуля alterator-x11.

Бишь скорее всего -- "ничего личного" :)  И тем более никаких
претензий персонально к тебе, поскольку зафиксированный
альтератор бывает весьма недурён.

Насчёт же того, что хороший инструмент помимо недурственности
обладает ещё и предсказуемостью -- и так уже слишком много тебя
грузил, да и сам знаешь.  thresh@ там высказался в точку.

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

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 20:49:53 Alexander Bokovoy wrote:
> 2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> > 14 ноября 2008 г. 21:01 пользователь Alexander Bokovoy
> >
> > <ab@altlinux.org> написал:
> >> 2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> >>> Можно придумать и более интересные применения этого модуля. Может
> >>> стоит нам использовать его возможности по умолчанию? Соответственно
> >>> исправить альтератор для работы с ним.
> >>
> >> Суммируя, этот модуль делает поддержку nested groups, раскрывая их во
> >> время исполнения.
> >> Модуль написан на C++ и в любое приложение в системе тянет за собой
> >> /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
> >
> > ...и отъедает 1 мб памяти на десктопе, если до этого там не было
> > запущено ни одного с++ приложения.
> > Сколько у нас дасктопов без единого С++ приложения? Альтератор для
> > своего ГУЯ тоже будет тянуть /usr/lib/libstdc++.so.6.0.10 и что?
>
> Можно отвечать по существу, а не заниматься флеймом?
>
> >> Теперь главный вопрос: чем не устраивает поддержка RFC2307bis в
> >> nss_ldap? Она существует с 2002 года и отлично работает.
> >
> > Гм, а как сетевые группы соотносятся с моим приложением? Вы его хоть
> > прочитали? Или вы предлагаете вместо того чтобы тянуть зависимость на
> > С++ поставить всем локально ldap?
>
> Можно отвечать по существу, а не заниматься флеймом?
>
> Я прочитал обоснование, которое в качестве примеров приводит типичные
> примеры администрирования однообразных машин в организациях. Нигде там
> не приведен use case, который специфичен для одного компьютера, везде
> речь идет об "администрировании большого парка компьютеров и большого
> числа пользователей".

100% - "для одного компьютера" - это бред.
А так, в моей практике был как минимум один случай, когда мне такое нужно было 
(LDAP и AD там было явно overhead)

-- 
Led

Re: [devel] Управление группами пользователя

[Stanislav Ievlev]

On Fri, Nov 14, 2008 at 09:35:35PM +0300, Dmitriy M. Maslennikov wrote:
> 14 ноября 2008 г. 21:01 пользователь Alexander Bokovoy
> <ab@altlinux.org> написал:
> > 2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> >> Можно придумать и более интересные применения этого модуля. Может
> >> стоит нам использовать его возможности по умолчанию? Соответственно
> >> исправить альтератор для работы с ним.
> > Суммируя, этот модуль делает поддержку nested groups, раскрывая их во
> > время исполнения.
> > Модуль написан на C++ и в любое приложение в системе тянет за собой
> > /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
> ...и отъедает 1 мб памяти на десктопе, если до этого там не было
> запущено ни одного с++ приложения.
> Сколько у нас дасктопов без единого С++ приложения? Альтератор для
> своего ГУЯ тоже будет тянуть /usr/lib/libstdc++.so.6.0.10 и что?
apt вытянет раньше ;)

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 20:35:35 Dmitriy M. Maslennikov wrote:
> 14 ноября 2008 г. 21:01 пользователь Alexander Bokovoy
>
> <ab@altlinux.org> написал:
> > 2008/11/14 Dmitriy M. Maslennikov <maslennikovdm@gmail.com>:
> >> Можно придумать и более интересные применения этого модуля. Может
> >> стоит нам использовать его возможности по умолчанию? Соответственно
> >> исправить альтератор для работы с ним.
> >
> > Суммируя, этот модуль делает поддержку nested groups, раскрывая их во
> > время исполнения.
> > Модуль написан на C++ и в любое приложение в системе тянет за собой
> > /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
>
> ...и отъедает 1 мб памяти на десктопе, если до этого там не было
> запущено ни одного с++ приложения.

А при чём тут десктоп? ИМХО это явно не для десктопа.
Сабж, вроде, может быть полезен для некоторых случаев. Но меня тоже удивило, 
что c++. Хотя, потом я подумал "Хорошо, что не на Python" и смирился:)

> Сколько у нас дасктопов без единого С++ приложения? Альтератор для
> своего ГУЯ тоже будет тянуть /usr/lib/libstdc++.so.6.0.10 и что?

-- 
Led

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 22:52 пользователь Led <ledest@gmail.com> написал:
> А при чём тут десктоп? ИМХО это явно не для десктопа.
А почему не для него? Именно для него!

> Сабж, вроде, может быть полезен для некоторых случаев. Но меня тоже удивило,
> что c++. Хотя, потом я подумал "Хорошо, что не на Python" и смирился:)
Просто на С++ писать удобнее (по крайней мере нам). Желающие могут
переписать на С. В случае современного десктопа С++ приложения
присутствуют в любом случае, так что ничего особенного мы не потянули.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 21:54:18 Dmitriy M. Maslennikov wrote:
> 14 ноября 2008 г. 22:52 пользователь Led <ledest@gmail.com> написал:
> > А при чём тут десктоп? ИМХО это явно не для десктопа.
>
> А почему не для него? Именно для него!

Ну и зря. Лично мне такой "десктоп" не нужен.

>
> > Сабж, вроде, может быть полезен для некоторых случаев. Но меня тоже
> > удивило, что c++. Хотя, потом я подумал "Хорошо, что не на Python" и
> > смирился:)
>
> Просто на С++ писать удобнее (по крайней мере нам). Желающие могут
> переписать на С.

А это, кстати, не исключено. Потому как в своё время именно такая штука нужна 
была, но разбираться с программированием для nss не было времени. А так, по 
готовому коду, возможно, будет значительно проще. Спасибо:)

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

Это не для десктопа.

-- 
Led

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 22:59 пользователь Led <ledest@gmail.com> написал:
> Ну и зря. Лично мне такой "десктоп" не нужен.
> Это не для десктопа.
То есть, это не для десктопа, потому что не для десктопа, я правильно
понял вашу мысль?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 22:03:52 Dmitriy M. Maslennikov wrote:
> 14 ноября 2008 г. 22:59 пользователь Led <ledest@gmail.com> написал:
> > Ну и зря. Лично мне такой "десктоп" не нужен.
> > Это не для десктопа.
>
> То есть, это не для десктопа, потому что не для десктопа, я правильно
> понял вашу мысль?

Мысль? Это просто моё (личное) мнение, не более того:)
Вы меня пытаетесь убедить, что эта штука может быть полезна? Я с этим 
согласен.

-- 
Led

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 23:09 пользователь Led <ledest@gmail.com> написал:
> Мысль? Это просто моё (личное) мнение, не более того:)
> Вы меня пытаетесь убедить, что эта штука может быть полезна? Я с этим
> согласен.
То есть вы утверждаете, что этот модуль полезен, но при этом против
того, чтобы он использовался на Desktop. Все-таки почему? Эта тема как
раз создана для выяснения этих вопросов.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 22:59 пользователь Led <ledest@gmail.com> написал:
>> Просто на С++ писать удобнее (по крайней мере нам). Желающие могут
>> переписать на С.
>
> А это, кстати, не исключено. Потому как в своё время именно такая штука нужна
> была, но разбираться с программированием для nss не было времени. А так, по
> готовому коду, возможно, будет значительно проще. Спасибо:)
NIH-синдром в чистом виде)

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Led]

On Friday, 14 November 2008 22:06:20 Dmitriy M. Maslennikov wrote:
> 14 ноября 2008 г. 22:59 пользователь Led <ledest@gmail.com> написал:
> >> Просто на С++ писать удобнее (по крайней мере нам). Желающие могут
> >> переписать на С.
> >
> > А это, кстати, не исключено. Потому как в своё время именно такая штука
> > нужна была, но разбираться с программированием для nss не было времени. А
> > так, по готовому коду, возможно, будет значительно проще. Спасибо:)
>
> NIH-синдром в чистом виде)

Это диагноз?:)

-- 
Led

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 23:14 пользователь Led <ledest@gmail.com> написал:
>> NIH-синдром в чистом виде)
>
> Это диагноз?:)
Может быть. Но я не пытался вас задеть. Просто констатировал факт. У
вас вполне может получиться лучше, чем у нас, тогда мы просто будем
использовать ваш модуль.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Управление группами пользователя

[Sergey Bolshakov]

>>>>> "Dmitriy" == Dmitriy M Maslennikov <maslennikovdm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

 > 14 ноября 2008 г. 22:52 пользователь Led <ledest@gmail.com> написал:
 >> А при чём тут десктоп? ИМХО это явно не для десктопа.
 > А почему не для него? Именно для него!

 >> Сабж, вроде, может быть полезен для некоторых случаев. Но меня тоже удивило,
 >> что c++. Хотя, потом я подумал "Хорошо, что не на Python" и смирился:)
 > Просто на С++ писать удобнее (по крайней мере нам). Желающие могут
 > переписать на С. В случае современного десктопа С++ приложения
 > присутствуют в любом случае, так что ничего особенного мы не потянули.

Посмотрите, где в файловой системе расположена libstdc++, а где
libnss_*. Подумайте, почему.

-- 

Re: [devel] Управление группами пользователя

[Evgeny Sinelnikov]

14 ноября 2008 г. 23:58 пользователь Sergey Bolshakov
<sbolshakov@altlinux.ru> написал:
>>>>>> "Dmitriy" == Dmitriy M Maslennikov <maslennikovdm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>  > 14 ноября 2008 г. 22:52 пользователь Led <ledest@gmail.com> написал:
>  >> А при чём тут десктоп? ИМХО это явно не для десктопа.
>  > А почему не для него? Именно для него!
>
>  >> Сабж, вроде, может быть полезен для некоторых случаев. Но меня тоже удивило,
>  >> что c++. Хотя, потом я подумал "Хорошо, что не на Python" и смирился:)
>  > Просто на С++ писать удобнее (по крайней мере нам). Желающие могут
>  > переписать на С. В случае современного десктопа С++ приложения
>  > присутствуют в любом случае, так что ничего особенного мы не потянули.
>
> Посмотрите, где в файловой системе расположена libstdc++, а где
> libnss_*. Подумайте, почему.
>
Может быть libstdc++ лежит не там, где ему место? :)))))

Я некоторое время назад, уже довольно давно, услышал фразу, что Linux
- это система написанная "сишниками для сишников". Знаете, я сейчас
ощущаю яркое тому подтверждение :)))

Так вот... вопросов, по большому счёту два... первый, и самый важный,
состоит в том, как комьюнити относится к решению в концептуальном
плане... на чём оно написано - на чистом C или С++ и boost - в этом
плане, никакой роли не играет... Важен тот момент, что проводится
некое расширение семантики интерпретации системных групп... А из этого
следует множество вариантов использования...

Второй же вопрос состоит в том, что кому-то не нравится как это
решение выполнено технически, и кто-то, в связи с этим, начинает
упрекать "автора в серьёзных проблемах с проектированием". Что, в
общем-то, само по себе, является тоже субъективным и спорным
моментом... ;)

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

Давайте смотреть правде в глаза, если к каждому решению в Сизифе
придираться, то тоже можно найти много чего (например,
потокобезопасность в libnss_winbind)... Я готов рассмотреть вопрос о
переписывании кода на С, но не вижу принципиальной в этом
необходимости. Если появится вторая реализация этого решения на C, я
буду только рад... Но самому писать этот код на C, особенно на
начальном этапе, у меня ни времени, ни желания. Я искренне не понимаю
зачем нужны супер решения, построенные примитивными средствами завтра,
вместо рабочих решений сегодня, когда цена вопроса 1Мб, который и так
в памяти почти всё время сидит... Особенно, это непонятно, с учётом
текущей модульной архитектуры.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Управление группами пользователя

[Dmitry V. Levin]

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

On Fri, Nov 14, 2008 at 09:01:56PM +0300, Alexander Bokovoy wrote:
[...]
> Модуль написан на C++ и в любое приложение в системе тянет за собой
> /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
> 
> Теперь главный вопрос: чем не устраивает поддержка RFC2307bis в
> nss_ldap? Она существует с 2002 года и отлично работает.

Не затрагивая основную тему, по мелочам.

Те библиотеки, которые тянет nss_ldap, гораздо опаснее для приложения,
чем libstdc++; простой модуль можно переписать на -lc, а вот nss_ldap
на -lc вряд ли перепишешь.


-- 
ldv

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

Re: [devel] Управление группами пользователя

[Evgeny Sinelnikov]

16 ноября 2008 г. 23:07 пользователь Dmitry V. Levin <ldv@altlinux.org> написал:
> On Fri, Nov 14, 2008 at 09:01:56PM +0300, Alexander Bokovoy wrote:
> [...]
>> Модуль написан на C++ и в любое приложение в системе тянет за собой
>> /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
>>
>> Теперь главный вопрос: чем не устраивает поддержка RFC2307bis в
>> nss_ldap? Она существует с 2002 года и отлично работает.
>

С другой стороны, я не понимаю причём тут вообще ldap. Будем считать,
что планирую использовать не nss_ldap, а скажем nss_mysql или
собственный модуль? И я хочу чтобы локальная политика была локальным
свойством рабочей станции?

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

> Не затрагивая основную тему, по мелочам.
>
> Те библиотеки, которые тянет nss_ldap, гораздо опаснее для приложения,
> чем libstdc++; простой модуль можно переписать на -lc, а вот nss_ldap
> на -lc вряд ли перепишешь.
>


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Управление группами пользователя

[Vitaly Lipatov]

On 16 ноября 2008, Evgeny Sinelnikov wrote:
> 16 ноября 2008 г. 23:07 пользователь Dmitry V. Levin 
<ldv@altlinux.org> написал:
> > On Fri, Nov 14, 2008 at 09:01:56PM +0300, Alexander Bokovoy
> > wrote: [...]
> >
> >> Модуль написан на C++ и в любое приложение в системе тянет
> >> за собой /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
> >>
> >> Теперь главный вопрос: чем не устраивает поддержка
> >> RFC2307bis в nss_ldap? Она существует с 2002 года и отлично
> >> работает.
>
> С другой стороны, я не понимаю причём тут вообще ldap. Будем
При том, что использование nss_ldap гораздо опаснее nss_role в 
плане возможных подобных эффектов.
И речь не о назначении nss-модуля, а о деталях его реализации.

> > Не затрагивая основную тему, по мелочам.
> >
> > Те библиотеки, которые тянет nss_ldap, гораздо опаснее для
> > приложения, чем libstdc++; простой модуль можно переписать
> > на -lc, а вот nss_ldap на -lc вряд ли перепишешь.



-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Управление группами пользователя

[Evgeny Sinelnikov]

17 ноября 2008 г. 2:44 пользователь Vitaly Lipatov <lav@altlinux.ru> написал:
> On 16 ноября 2008, Evgeny Sinelnikov wrote:
>> 16 ноября 2008 г. 23:07 пользователь Dmitry V. Levin
> <ldv@altlinux.org> написал:
>> > On Fri, Nov 14, 2008 at 09:01:56PM +0300, Alexander Bokovoy
>> > wrote: [...]
>> >
>> >> Модуль написан на C++ и в любое приложение в системе тянет
>> >> за собой /usr/lib/libstdc++.so.6.0.10 (порядка 1Мб).
>> >>
>> >> Теперь главный вопрос: чем не устраивает поддержка
>> >> RFC2307bis в nss_ldap? Она существует с 2002 года и отлично
>> >> работает.
>>
>> С другой стороны, я не понимаю причём тут вообще ldap. Будем
> При том, что использование nss_ldap гораздо опаснее nss_role в
> плане возможных подобных эффектов.
> И речь не о назначении nss-модуля, а о деталях его реализации.
>

Да, я это понял.... Наверное стоило ответить в другую часть ветки... Я
хотел вести речь про первоначальный вопрос о том, чем не устроила
"поддержка RFC2307bis в nss_ldap"... К чему и относился момент о том,
что я не понимаю "причём тут вообще ldap".

Кстати, я посмотрел RFC2307bis, там действительно перечислены
некоторые элементы системной базы Unix, которыми я полагаю, стоит
воспользоваться... Как шаблон для реализации своего модуля, этот RFC
крайне полезен...

>> > Не затрагивая основную тему, по мелочам.
>> >
>> > Те библиотеки, которые тянет nss_ldap, гораздо опаснее для
>> > приложения, чем libstdc++; простой модуль можно переписать
>> > на -lc, а вот nss_ldap на -lc вряд ли перепишешь.



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Управление группами пользователя

[Alexey I. Froloff]

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

* Dmitriy M. Maslennikov <maslennikovdm@> [081114 20:05]:
> С помощью NSS модуля, разработанного нами, можно решить эту проблему
> более красивым способом.
C++ и boost - это красиво?

-- 
Regards,
Sir Raorn.

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

Re: [devel] Управление группами пользователя

[Stanislav Ievlev]

On Fri, Nov 14, 2008 at 11:16:03PM +0300, Alexey I. Froloff wrote:
> * Dmitriy M. Maslennikov <maslennikovdm@> [081114 20:05]:
> > С помощью NSS модуля, разработанного нами, можно решить эту проблему
> > более красивым способом.
> C++ и boost - это красиво?
Давайте всё-таки не будем углубляться во флейм насчёт средств разработки ;)

Re: [devel] Управление группами пользователя

[Alexey I. Froloff]

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

* Stanislav Ievlev <inger@> [081114 23:25]:
> > > С помощью NSS модуля, разработанного нами, можно решить эту проблему
> > > более красивым способом.
> > C++ и boost - это красиво?
> Давайте всё-таки не будем углубляться во флейм насчёт средств разработки ;)
У меня очень большой опыт чтения (и исправления) кривого кода на
разных языках.  Если для такой, в общем-то простой задачи
используется C++ и boost, то с большой вероятностью я могу
допустить, что у автора серьёзные проблемы с проектированием.

Вот только что на канале вспоминал "девел логгирования" с моей
бывшей работы на C++ и boost (и php-модуль к нему, такой же).

P.S. Те же alternatives были переписаны на shell+awk ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] Управление группами пользователя

[Stanislav Ievlev]

On Fri, Nov 14, 2008 at 11:37:05PM +0300, Alexey I. Froloff wrote:
> P.S. Те же alternatives были переписаны на shell+awk ;-)
Ага, и после этого начали меня клеймить любители xml ;)

Да и переписаны были не потому что C++, а потому что в какой-то момент
захотелось попробовать другого ;))

P.S. Я  исправлял много кривого кода на С ;)

Re: [devel] Управление группами пользователя

[Dmitriy M. Maslennikov]

14 ноября 2008 г. 23:16 пользователь Alexey I. Froloff
<raorn@altlinux.ru> написал:
> * Dmitriy M. Maslennikov <maslennikovdm@> [081114 20:05]:
>> С помощью NSS модуля, разработанного нами, можно решить эту проблему
>> более красивым способом.
> C++ и boost - это красиво?
Это совсем уже offtop. Но да использование NSS модуля, написанного на
С++ с использованием boost красивее того, как эта проблема решена
сейчас.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru