[room] glibc -- яркий пример проблем, аналогичных нашим

[room] glibc -- яркий пример проблем, аналогичных нашим

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

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

http://avva.livejournal.com/2323823.html

Что-то мне это очень напоминает. У нас такие разборки в devel@ чуть ли не
раз в месяц :(

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [room] glibc -- яркий пример проблем, аналогичных нашим

[Евгений Ростовцев]

03.04.11, Денис Смирнов<mithraen@freesource.info> написал(а):
> http://avva.livejournal.com/2323823.html
>
> Что-то мне это очень напоминает. У нас такие разборки в devel@ чуть ли не
> раз в месяц :(

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

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [room] glibc -- яркий пример проблем, аналогичных нашим

[Евгений Ростовцев]

03.04.11, Денис Смирнов<mithraen@freesource.info> написал(а):
> http://avva.livejournal.com/2323823.html

Переслал ldv@ и заодно at@.

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [room] glibc -- яркий пример проблем, аналогичных нашим

[Aleksey Novodvorsky]

2 апреля 2011 г. 22:18 пользователь Евгений Ростовцев
<real.altlinux.org@gmail.com> написал:
> 03.04.11, Денис Смирнов<mithraen@freesource.info> написал(а):
>> http://avva.livejournal.com/2323823.html
>
> Переслал ldv@ и заодно at@.

По крайней мере ldv@ знает эту историю раншье поста avva@, как
разработчик glibc.
У нас пока версия glibs без оптимизации от Intel, но когда мы перейдем
на новую, то ldv@ включит исправления, предложенные Линусом или их
вариант, в этом он меня заверил. И это нормальное поведение его как
_мейнтенера_ glibc в Альт.
Хочу все же, если уж тема поднята тут, заметить вот что.
Ядра, выпускаемые Линусом, никто не использует as is. Более того, он и
сам рекомендует ядра из дистрибутивов. Это понятно, так как ему не
хочется вносить сомнительный код. Но этот код нужен пользователям, так
как поддерживает их устройства и нужные фичи.
Почему же Линус требует от разработчиков glibc то, что сам не делает?
(Небольшая провокация, да. Но я хочу подчеркнуть, что тема не такая
простая и надо хорошо понимать процесс и области ответственности,
чтобы ее обсуждать.)

Rgrds, Алексей
>
> --
> REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
> _______________________________________________
> smoke-room mailing list
> smoke-room@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/smoke-room

Re: [room] glibc -- яркий пример проблем, аналогичных нашим

[Евгений Ростовцев]

>>> http://avva.livejournal.com/2323823.html
>>
>> Переслал ldv@ и заодно at@.
>
> По крайней мере ldv@ знает эту историю раншье поста avva@, как
> разработчик glibc.
> У нас пока версия glibs без оптимизации от Intel, но когда мы перейдем
> на новую, то ldv@ включит исправления, предложенные Линусом или их
> вариант, в этом он меня заверил.

Хорошо.

> Почему же Линус требует от разработчиков glibc то, что сам не делает?
> (Небольшая провокация, да. Но я хочу подчеркнуть, что тема не такая
> простая и надо хорошо понимать процесс и области ответственности,
> чтобы ее обсуждать.)

Я бы не стал флеймить на эту тему. Меня заинтересовала чисто
техническая часть поднятого вопроса. А "разборок" мне и в devel@
хватает.

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [room] glibc -- яркий пример проблем, аналогичных нашим

[Aleksey Novodvorsky]

2 апреля 2011 г. 22:34 пользователь Евгений Ростовцев
<real.altlinux.org@gmail.com> написал:
>>>> http://avva.livejournal.com/2323823.html
>>>
>>> Переслал ldv@ и заодно at@.
>>
>> По крайней мере ldv@ знает эту историю раншье поста avva@, как
>> разработчик glibc.
>> У нас пока версия glibs без оптимизации от Intel, но когда мы перейдем
>> на новую, то ldv@ включит исправления, предложенные Линусом или их
>> вариант, в этом он меня заверил.
>
> Хорошо.
>
>> Почему же Линус требует от разработчиков glibc то, что сам не делает?
>> (Небольшая провокация, да. Но я хочу подчеркнуть, что тема не такая
>> простая и надо хорошо понимать процесс и области ответственности,
>> чтобы ее обсуждать.)
>
> Я бы не стал флеймить на эту тему. Меня заинтересовала чисто
> техническая часть поднятого вопроса. А "разборок" мне и в devel@
> хватает.

Техническая часть простая. В glibc код соответствует стандарту. Точка.
Glibc -- продукт для разработчиков и не должен включать послабления
для их кривых рук. А вот дистрибутивы -- должны, так как пользователя
не касаются проблемы разработчиков. С одной важной оговоркой. Мы не
знаем бизнес-задач Fedora. Возможно, эти исправления не включаются в
дистрибутив из соображений бизнеса, и тут они в  своем праве, нравится
это кому-то или нет.

Rgrds, Алексей

Re: [room] glibc -- яркий пример давно известных проблем

[Michael Shigorin]

On Sat, Apr 02, 2011 at 10:44:52PM +0400, Aleksey Novodvorsky wrote:
> Техническая часть простая. В glibc код соответствует стандарту. Точка.

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

> Glibc -- продукт для разработчиков и не должен включать
> послабления для их кривых рук.

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

> А вот дистрибутивы -- должны, так как пользователя не касаются
> проблемы разработчиков. С одной важной оговоркой. Мы не знаем
> бизнес-задач Fedora.

Озвученная -- помнится, бета-тестирование RHEL.

PS: ...интересно, достанет ли Дреппер Линуса настолько,
чтоб glibc (с патчами eglibc, Owl/ALT и прочими отличиями
вроде обсуждаемого) все стали брать с kernel.org :)

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

Re: [room] glibc -- яркий пример давно известных проблем

[Евгений Ростовцев]

> PS: ...интересно, достанет ли Дреппер Линуса настолько,
> чтоб glibc (с патчами eglibc, Owl/ALT и прочими отличиями
> вроде обсуждаемого) все стали брать с kernel.org :)

Лучше бы достал :)

К Линусу как-то доверия больше.

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [room] glibc -- яркий пример давно известных проблем

[Aleksey Novodvorsky]

2011/4/4 Michael Shigorin <mike@osdn.org.ua>:
> On Sat, Apr 02, 2011 at 10:44:52PM +0400, Aleksey Novodvorsky wrote:
>> Техническая часть простая. В glibc код соответствует стандарту. Точка.
>
> Насколько понимаю, в данном случае стандарт не специфицирует
> поведение, поэтому говорить о соответствии либо несоответствии
> не приходится.
>
>> Glibc -- продукт для разработчиков и не должен включать
>> послабления для их кривых рук.
>
> Почему?  Пишется он тоже разработчиками, и как недавняя
> уязвимость показала -- руки у них тоже согнуты в локтях.
>
>> А вот дистрибутивы -- должны, так как пользователя не касаются
>> проблемы разработчиков. С одной важной оговоркой. Мы не знаем
>> бизнес-задач Fedora.
>
> Озвученная -- помнится, бета-тестирование RHEL.

Нет. Плохо Вам помнится. А Вы ведь выводы делаете прежде, чем погуглить.

Rgrds, Алексей

Re: [room] glibc -- яркий пример давно известных проблем

[Michael Shigorin]

On Mon, Apr 04, 2011 at 02:28:51PM +0400, Aleksey Novodvorsky wrote:
> >> А вот дистрибутивы -- должны, так как пользователя не касаются
> >> проблемы разработчиков. С одной важной оговоркой. Мы не знаем
> >> бизнес-задач Fedora.
> > Озвученная -- помнится, бета-тестирование RHEL.
> Нет. Плохо Вам помнится.

Возможно.  В основном припоминается выжимка времён появления
fedora при существующей fedora.us.

> А Вы ведь выводы делаете прежде, чем погуглить.

А я погуглил, Алексей Евгеньевич.  Возвращаю. :)

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

Re: [room] glibc -- яркий пример давно известных проблем

[Aleksey Novodvorsky]

2011/4/4 Michael Shigorin <mike@osdn.org.ua>:
> On Mon, Apr 04, 2011 at 02:28:51PM +0400, Aleksey Novodvorsky wrote:
>> >> А вот дистрибутивы -- должны, так как пользователя не касаются
>> >> проблемы разработчиков. С одной важной оговоркой. Мы не знаем
>> >> бизнес-задач Fedora.
>> > Озвученная -- помнится, бета-тестирование RHEL.
>> Нет. Плохо Вам помнится.
>
> Возможно.  В основном припоминается выжимка времён появления
> fedora при существующей fedora.us.
>
>> А Вы ведь выводы делаете прежде, чем погуглить.
>
> А я погуглил, Алексей Евгеньевич.  Возвращаю. :)

Бага на 2.12, в RHEL6 2.11

Rgrds, Алексей

Re: [room] glibc -- яркий пример давно известных проблем

[Aleksey Novodvorsky]

4 апреля 2011 г. 14:43 пользователь Aleksey Novodvorsky
<a.e.nvdv@gmail.com> написал:
> 2011/4/4 Michael Shigorin <mike@osdn.org.ua>:
>> On Mon, Apr 04, 2011 at 02:28:51PM +0400, Aleksey Novodvorsky wrote:
>>> >> А вот дистрибутивы -- должны, так как пользователя не касаются
>>> >> проблемы разработчиков. С одной важной оговоркой. Мы не знаем
>>> >> бизнес-задач Fedora.
>>> > Озвученная -- помнится, бета-тестирование RHEL.
>>> Нет. Плохо Вам помнится.
>>
>> Возможно.  В основном припоминается выжимка времён появления
>> fedora при существующей fedora.us.
>>
>>> А Вы ведь выводы делаете прежде, чем погуглить.
>>
>> А я погуглил, Алексей Евгеньевич.  Возвращаю. :)
>
> Бага на 2.12, в RHEL6 2.11
>

Виноват, смотрел на бету.
Извините.
Тем более это вопрос бизнеса
Rgrds, Алексей

Re: [room] glibc -- яркий пример проблем, аналогичных нашим

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

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

On Sat, Apr 02, 2011 at 10:30:55PM +0400, Aleksey Novodvorsky wrote:

AN> Почему же Линус требует от разработчиков glibc то, что сам не делает?
AN> (Небольшая провокация, да. Но я хочу подчеркнуть, что тема не такая
AN> простая и надо хорошо понимать процесс и области ответственности,
AN> чтобы ее обсуждать.)

Линусу можно, он не работает на авторов дистрибутива. Для glibc он
пользователь.

Если бы в федоре пакетилось с исправлением этой проблемы вопросов бы не
было.

Кроме того была озвучена разумная мысль -- так как нынешний memcpy уже не
является простым, из-за оптимизаций Intel, то небольшое изменение которое
позволило бы сделать поведение memcpy идентичным поведению memmove имеет
смысл.

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

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

http://mithraen.ru/
----------------------------------------------------------------------------

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