LINUX.ORG.RU

Смена власти в проекте Glibc, уход Ульриха Дреппера из управления проектом

 ,


0

1

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

Джозеф Маерс, один из мейнтейнеров Glibc, пригласил энтузиастов принять участие в разработке Glibc и указал на то, что соблюдая правила GNU и не отходя от устоявшихся в сообществе норм и стиля кодирования, участники разработки могут претендовать на получение права коммита. В будущем не исключено решение всех разногласий с разработчиками еglibc и постепенную интеграцию расширенных функций еglibc в glibc, что в итоге может привести к слиянию обеих системных библиотек в единый проект.

Среди утверждённых мэйнтейнеров отмечены Рональд Макграт, Райан Арнольд, Максим Кувырков, Джозеф Маерс, Карлос О'Донелл и Алехандре Олива. Примечательно, но в списке нет Ульриха Дреппера, который отмечен на сайте Glibc как наиболее влиятельный разработчик, отвечающий за приём патчей и сопровождение проекта. В сообщении о роспуске комитета выражается благодарность Ульриху Дрепперу за вклад в развитие Glibc, но он не включён в новую команду мэйнтейнеров, что связано с его уходом из компании Red Hat и невозможности тратить много времени на проект (работа в RedHat подразумевала трату на Glibc всего рабочего времени).

Новость взята с opennet.ru

>>> Подробности

★★★★★

Проверено: tazhate ()
Последнее исправление: JB (всего исправлений: 3)

Ответ на: комментарий от Legioner

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

Никто и не вставлял. Форкай libc или поддерживай патчи, кто же запретит то. А в центральную ветку со своими псевдоязыками лезть не надо.

Ню-ню.

Тем более, что никому эта поддержка не мешает.

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

А я не хочу качать ни одного байта из переводов, нужных тебе. Давай и их выкинем заодно? :-)

rtvd ★★★★★
()
Ответ на: комментарий от geekless

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

MyTrooName ★★★★★
()
Ответ на: комментарий от rtvd

А я не хочу качать ни одного байта из переводов, нужных тебе. Давай и их выкинем заодно? :-)

давно пора локали держать отдельно, а не тащить весь зоопарк.

anonymous
()
Ответ на: комментарий от cvs-255

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

AptGet ★★★
()
Ответ на: комментарий от anonymous

давно пора локали держать отдельно, а не тащить весь зоопарк.

Согласен.

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

А я не хочу качать ни одного байта из переводов, нужных тебе. Давай и их выкинем заодно? :-)

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

Legioner ★★★★★
()
Ответ на: комментарий от Gunnerua

Не хочешь - делай форк под названием «руссишglibc» и люди к тебе потянутся.

Не хочешь эсперанто в glibc - делай форк под названием retardglibc. И соответствующие люди к тебе потянутся.

rtvd ★★★★★
()
Ответ на: комментарий от Legioner

Но с тем, что кто-то придумывает новые языки непонятно зачем я смириться не готов.

Зря ты так нелюбишь языки. Они - хорошие.

rtvd ★★★★★
()
Ответ на: комментарий от Loki13

извиняюсь, никого не хотел обидеть, просто слегка гиперболизировал для ясности.

тут мы имеем не плеер, не клиент-серверно-распределенное приложение, а операционную систему^W^W несколько операционных систем, состоящих из _взаимозаменяемых_ приложений, см. юникс-вей. а глибц - ключевая часть большинства окружений.

просто откатить изменения в глибц будет недостаточно, придется менять стандарт, а следом приводить все остальные ulibc и компанию в соответствие новому стандарту.

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

MyTrooName ★★★★★
()
Ответ на: комментарий от geekless

предположение, что qsort используется в этих ваших ПРИЛОЖЕНИЯХ считаю самоочевидным.

MyTrooName ★★★★★
()
Ответ на: комментарий от Legioner

Что же в них хорошего? Разнообразие языков - один из основных тормозов на пути прогресса.

А я думал, что один из основных тормозов на пути прогресса - неумение / нежелание познать новое (в частности, выучить еще один язык).

rtvd ★★★★★
()
Ответ на: комментарий от AptGet

DMA настраивать дольше, чем пара проверок, как минимум надо контекст переключать.

Зависит от реализации DMA engine и объема компируемых данных.

tailgunner ★★★★★
()
Ответ на: комментарий от geekless

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

MyTrooName ★★★★★
()
Ответ на: комментарий от Legioner

считается, что эсперанто очень прост для изучения. я сам не в теме, но 2 миллиона эсперантистов не могут ошибаться :)

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

и, кстати, для цифрового распознавания текста

MyTrooName ★★★★★
()
Ответ на: комментарий от imul

В общем если dst > src то копировать нужно от конца к началу. Вариант который проверен и работает :)

A-234 ★★★★★
()
Ответ на: комментарий от Legioner

>когда качаю исходники

Это проблемы индейцев, а у нас тут вендекапец, десктопы и прочее народное счастье.

Deleted
()
Ответ на: комментарий от tailgunner

Зависит от реализации DMA engine и объема компируемых данных.

А можно пример подходящего DMA engine? Мне интересно как это работает :)

AptGet ★★★
()
Ответ на: комментарий от Manhunt

Зато в мэйллистах теперь все будут вежливые и почтительные. :D

imul ★★★★★
()
Ответ на: комментарий от cvs-255

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

A-234 ★★★★★
()
Ответ на: комментарий от anonymous

А это странно, они по идее одним ветвлением различаются. Будем считать, что ты меня убедил.

geekless ★★
()
Ответ на: комментарий от AptGet

А можно пример подходящего DMA engine?

А на какой-то архитектуре есть устрйоство для DMA-копирования памяти. Ну и обычный здравый смысл подсказывает, что сколько бы не стоил setup/teardown, он окупится на достаточно большом объеме копирования.

tailgunner ★★★★★
()
Ответ на: комментарий от rtvd

То, что какому-нибудь папуасу не нужен эсперанто

Эк ты ловко назвал папуасами 6998000000 человек. Да ещё оказывается и у меня проблемы. Ню-ню.

imul ★★★★★
()
Ответ на: комментарий от anonymous

А знаешь, анон, до меня дошло. Прочитал вон комментом выше:

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

и дошло.

memcpy может быть встроена компилятором прямо в код. Поэтому её нельзя прятать в шкаф от программиста.

geekless ★★
()
Ответ на: комментарий от Legioner

Никто и не вставлял. Форкай libc или поддерживай патчи, кто же запретит то.

Вот такая политика и привела к тому, что с Ульриком вежливо распрощались.

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

Меньше чем «идиотский» сей «аргумент» нельзя назвать при всем желании. Не плачь и познакомься уже с системами контроля версий.

myhand
()
Ответ на: комментарий от A-234

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

уже сказалось. 60% оверхед, бенчмарк выше по треду

MyTrooName ★★★★★
()
Ответ на: комментарий от A-234

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

Если DMA настолько шустрое, что копирует за сопоставимое время, то разница будет ощутима.

Это как сравнивать 1 нм и 1,5 нм. Вроде бы больше всего на 0,5 нм, но при этом в полтора раза.

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

если разработчик memcpy отныне обязан копировать перекрывающиеся регионы особым образом, то UB в доках - прямое 4.2

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

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

MyTrooName ★★★★★
()
Ответ на: комментарий от segfault

Вообще-то я про Дреппера...

Ну, я этого не понял из контекста :)

AptGet ★★★
()
Ответ на: комментарий от MyTrooName

Пока что разработчик обязан делать систему соответствующюю текущему стандарту. А в стандарте UB. И, видимо, еще долго там будет. потому что задача memcpy - скопировать побыстрее. А на разных архитектурах это реализуется по-разному.

cvs-255 ★★★★★
()
Ответ на: комментарий от MyTrooName

просто откатить изменения в глибц будет недостаточно

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

Loki13 ★★★★★
()
Ответ на: комментарий от geekless

а если бы у бабушки был пенис, она была бы дедушкой

убедитесь, что memcpy инлайнится, а memmove - нет, потом оспаривайте надежность теста.

Поэтому её нельзя прятать в шкаф от программиста.

инкапсулировать можно все что угодно

MyTrooName ★★★★★
()
Ответ на: комментарий от cvs-255

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

MyTrooName ★★★★★
()
Ответ на: комментарий от Loki13

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

с учетом этого, откатывание тут при том, что баг обнаружили уже после релиза глибц

MyTrooName ★★★★★
()
Ответ на: комментарий от geekless

аргументы к личности не рассматриваю

поясните тогда, пожалуйста, что вы имели ввиду:

А знаешь, анон, до меня дошло. Прочитал вон комментом выше:

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

и дошло.

memcpy может быть встроена компилятором прямо в код. Поэтому её нельзя прятать в шкаф от программиста.

MyTrooName ★★★★★
()
Ответ на: комментарий от A-234

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

И забить на переносимость? эта самая memcpy может инлайниться автоматически, на уровне компилятора.

MyTrooName ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.