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)

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

Единственная причина так не делать — это показать такую реальную задачу, где memmove не подходит по производительности

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

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

Мир, э..., «немного изменился» - радио там всякое, телевидение; тырнет, наконец. Известная доля изоляции разве не необходима для появление диалектов языка?

Конечно, ведь «падонкаффский», упячкосленг и прочий луркояз возникли и скончались от старости в эпоху до исторического матерьялизьма, задолго до появления мобилок там, книгопечатания, вот этого вот всего.

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

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

Не убедил. Цена выбора «запускаем копирыватель или копируем как обычно» — 2 условных перехода. Это копейки.

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

Конечно, ведь «падонкаффский», упячкосленг и прочий луркояз возникли и скончались от старости в эпоху до исторического матерьялизьма, задолго до появления мобилок там, книгопечатания, вот этого вот всего.

Это не диалекты, а жаргоны.

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

Т.е. если будет очередное Г наподобие бага в flash player, есть опасность, что в glibc засунут «исправляющий» его костыль?

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

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

В информационную эпоху эсперанто просто последует туда же, куда последуют абсолютное большинство естественных языков — в могилу.

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

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

язык будующего же не?

Да я не против. Я ж не Ульрих. :D
Но, попоболь адептов весьма забавна. Аж два игнораста из-за этой темы. Причём, кроме какого-то мычания и отсылки к дискуссиям, которые они сами не читали, поскольку не могут оттуда надёргать каких-либо значимых аргументов, уже явно клинический случай.

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

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

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

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

Это следствие повышенной озабоченности у представителей меньшинств. Из той же серии, что и гей-парады.

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

Ну и кому она нужна?

Она нужна эсперантистам. К.О.

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

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

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

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

Я какбэ сразу про конкретный случай писал и под него базу подводил

Loki13 ★★★★★
()

раз эсперанто хотят включать, то надо ещё все толкиновские языки. квенья там, синдарин и т.д.

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

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

Поскольку производительность memcpy от memmove отличается парой условных переходов, то вывод: это просто удобный случай для троллинга и ничего более. Ага.

geekless ★★
()

К вопросу об эффективности memcpy vs memmove.

Алгоритм qsort, данные размером 32 байта, 32K элементов:

[joe@localhost sorting]$ valgrind --tool=cachegrind ./qsort-memcpy ... ==7183== I refs: 32,986,501 ...

[joe@localhost sorting]$ valgrind --tool=cachegrind ./qsort-memmove ... ==7203== I refs: 52,224,694 ...

Применение memmove() вместо memcpy() в данном случае приводит к оверхеду +60%.

Вы всё ещё настаиваете из memcpy() делать memmove()?

Ульрих, в отличие от некоторых, понимает почему настаивает на том или ином решении. Жаль, в его лице glibc может многое потерять, если на смену Ульриху придут так называемые «активные разработчики» (мем imho в чём-то похож с мемом «эффективные менеджеры»).

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

скорее всего вы ничего сложнее плеера никогда не писали.

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

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

Это не диалекты, а жаргоны.

жаргон образуется не в обособленной группе? Пруф?

//hint: у диалекта обособление по географическому признаку, для жаргона такое ограничение не накладывается.

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

Причина включать — наличие ISO-кода и наличие того, кто согласен это поддерживать.

Если бы ты удосужился почитать дискуссию и понять её, то ты бы заметил, что я добивался именно аргументов. И про iso мне аргумент привели. Мало того, я этот аргумент назвал очень весомым. А вот аргумент «нас аж два миллиона» это вообще не аргумент. По крайней мере он элементарно опровергается арифметикой.

Причин не включать нет.

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

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

Дреппера больше нет. Путь открыт. Ждём 2.15.1.

Как и ты.

А ты так ничего и не понял, хотя и ввязался. Как тогда, в треде про компиляцию в /usr/local/

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

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

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

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

Если есть аппаратный копирователь, то запустить его - те же 2-4 команды. И проверка уменьшает производительность в 1,5 - 2 раза

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

Эсперанто где-то является официальным языком? Если для каждого бормотания локаль делать, ни одна кровать не выдержит.

Да-да, разумеется ты не тролль, ты главное не нервничай. Ты не тролль, американцы не были на Луне, в шкафу живёт барабашка, всё хорошо.

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

Ждём 2.15.1.

Как бы не оказалось, что нас ждут 3.0, потом 4.0, и так далее... Так что об универсальных кросс-дистрибутивных бинарниках можно будет не мечтать. Вполне в духе «активной разработки».

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

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

Вот именно за это отвечают дистростроители.

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

У нас НЕТ аппаратного копирывателя. У нас конкретнная реализация в сорцах. Дреппер сэкономил десяток процессорных инструкций, лежащих вне копирующего цикла? Бгг, верю-верю.

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

ARM достаточно широко распространена для поддержки проектом GNU, я считаю. Говенность x86 не мешает поддерживать ее официально. Очевидно, Дреппер считает иначе.

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

для 100% выводов в данной области как минимум недостаточно данных.

грубо говоря, на примере: в 25 веке может быть, скажем, 3 диалекта эсперанто: диалект 20 века, диалект 22 века, и современный. первые два будут встречаться в основном в письменном (чаще электронном) виде, последний будет активно использоваться в том числе и в разговорной речи.

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

но это все теории. у эсперанто есть все шансы стать универсальным за это время, 3 диалекта - все же лучше, чем по 9000 диалектов у 100500 языков.

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

Хотелось бы услышать реальные аргументы «за». В частности статус этого неестественного малонужного языка.

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

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

Дреппер ща в Голдман Сакс работает

- Куда делся лимон баксов с моего счета? - Won't fix.

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

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

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

Дреппер сэкономил десяток процессорных инструкций

Несколькими сообщениями выше я не поленился запустить тест и показал, что это не десяток инструкций, а +60% для вполне реальной задачи. А вот чем практическим обоснован ваш лепет?

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

Нет, милейший, вы доказываете что-то самому себе. Требуется доказывать это утверждение не для вашей воображаемой memcpy и вашей воображаемой поддержки DMA в glibc, а для ПРИЛОЖЕНИЙ, использующих конкретную memcpy из конктретной библиотеки.

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

У нас НЕТ аппаратного копирывателя. У нас конкретнная реализация в сорцах.

Реализация в сырцах конкретная, но вот что это по-твоему, если не «копирыватель»:

  45       /* Copy whole pages from SRCP to DSTP by virtual address manipulation,
  46          as much as possible.  */
  47 
  48       PAGE_COPY_FWD_MAYBE (dstp, srcp, len, len);

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

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

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

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

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

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

Несколькими сообщениями выше я не поленился запустить тест и показал, что это не десяток инструкций, а +60% для вполне реальной задачи.

Я не вижу никакого теста в треде.

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

Цена выбора «запускаем копирыватель или копируем как обычно» — 2 условных перехода. Это копейки.

твои слова?

А использование слова «милейший» - хамство и фамильярность.

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

Зато потом он все копирует сильно быстрее. А если использовать сразу несколько каналов по количеству каналов доступа к памяти, так вообще куда быстрее копирования процессором. На слабых процессорах это особо заметно.

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