Орельен Ярно (Aurelien Jarno), один из мэйнтейнеров пакетов с системной библиотекой libc, объявил (http://blog.aurel32.net/175) о возвращении дистрибутива Debian GNU/Linux на использование Glibc (GNU C Library), вместо поставки библиотеки Eglibc (http://www.eglibc.org/) (Embedded GLIBC), на которую дистрибутив перешёл (http://www.opennet.me/opennews/art.shtml?num=21615) пять лет назад. В настоящее время пакеты c GLibc уже загружены в экспериментальный репозиторий Debian. Имена пакетов не изменились, процесс миграции будет полностью прозрачен для пользователей. В качестве причины возвращения к GLibc называется потеря смысла в разработке Eglibc (по словам Орельена проект "умер") после выпуска последнего релиза GLibc 2.19 (http://www.opennet.me/opennews/art.shtml?num=39043).
Проект Eglibc был основан в ответ на слишком жесткую и централизованно контролируемую политику приёма изменений в GLibc. В Eglibc был изменён процесс сборки для предоставления возможности гибкого управления включением разных компонентов, улучшена поддержка кросс-компиляции и кросс-тестирования, обеспечено включение дополнительных режимов оптимизации, приняты дополнительные патчи. При этом Eglibc не был форком GLibc, а лишь являлся доработанной пересборкой, построенной на актуальной кодовой базе Glibc и полностью совместимой с ней на уровне API и ABI.
Два года назад методы управления разработкой Glibc кардинально поменялись (http://www.opennet.me/opennews/art.shtml?num=33461): от управления проектом отстранился Ульрих Дреппер (Ulrich Drepper), который ранее единолично контролировал процесс приёма патчей и сопровождение проекта. Полномочия по принятию решений перешли в руки команды активных мэйнтейнеров. Разногласия с разработчиками еglibc были исчерпаны и был взят курс на совместную работу, постепенную интеграцию расширенных возможностей еglibc в glibc и последующее объединение проектов.
В настоящее время все наиболее важные возможности Eglibc уже перенесены в GLibc. В том числе переименованы зарезервированные ключевые слова и обеспечена возможность использования POSIX shell вместо bash. Создана стабильная ветка, в которую оперативно вносятся исправления. Прекращено разделение архитектур на основные (x86, SuperH, SPARC) и вторичные (ARM, MIPS), ранее размещённые в отдельном репозитории glibc-ports.
Исключением, мешавшим возвращению Debian на Eglibc, оставалась поддержка гибкой настройки компонентов (сборка с флагом "-Os" и без поддержки NIS и RPC), которую планировалось использовать в Debian-Installer. Но план потерял актуальность в связи с незничительным выигрышем в размере библиотеки на фоне динамичного развития аппаратных платформ. В итоге, в настоящий момент только пять доступных в Eglibc патчей не перенесены в GLibc: установка файлов *_pic.a для использования в mklibs, динамическая перезагрузка /etc/resolv.conf, установка заголовков при загрузке, обходное решение проблем с CPU PowerPC 8xx и доступ к FPSCR для процессоров SuperH с ядром SH4.
URL: http://blog.aurel32.net/175
Новость: http://www.opennet.me/opennews/art.shtml?num=40033
Ерундой занимаются.
> Ерундой занимаются.– Позвольте узнать, что вы можете сказать по поводу прочитанного?
– Да не согласен я.
– Что, с Энгельсом или с Каутским?
– С обоими.
Да все проще :). Дреппер свалил в туман, вот смысл в eglibc и отпал. Просто Дреппер был редким к@злом, с которым конструктивно решить вопросы было на редкость проблематично.
Торвальдс, Столман - они другие? В их храме тоже хрен в алтарь на--рёшь.
Случай с memcpy наглядно показал разницу между Дреппером и Торвальдсом.
кстати да, тоже вспомнилось: http://avva.livejournal.com/2323823.html
> кстати да, тоже вспомнилось: http://avva.livejournal.com/2323823.htmlНу и что вытекает из того что какой-то упорно и широко навязываемый плюгин вдруг перестал работать? И начал требовать совместимости и приспособления к его багам? Вместе с пользователями ничего не смыслящими во всех смыслах но просто мечтающими завести этот упорно навязываемый им и всем прочим плюгин в Линукс.
Кстати определение memcpy никак не менялось и не должно. И Drepper тут не поможет. И вполне возможно что в дальнейшем возникнут ещё неожиданности, даже если кому-то кажется, что эта функция теперь должна работать совместимо с багами и ошибками в их программах.
просто говнокодеры яростно защищают свой говнокод. это же проще, чем чинить.а линус вообще мудак известный.
Не понимаю. Была тупая функция memcpy(), которая была полезна в 70-е годы на очень низких процессорах, и которую легко реализовать на ассемблере. В 2010 году из Интела пришёл коммит, значительно усложняющий memcpy(), и его приняли. Если раньше функция могла писать "от начала к концу" и больше никак, то теперь появился второй вариант "от конца к началу". Возможно что коммит приняли из-за того что второе поведение добавляется только для процессоров с технологией SSE4.1, поэтому неправильную работу никто из тестеров не заметил.Разве не логично было просто взять и откатить коммит? При том что абсолютно никто не предоставил результаты тестов, показывающие что программы ускорились. А не рассуждать про "нарушены ли стандарты" и делать алиас memcpy-memmove? Смотрю обсуждение и вижу что про тот коммит вообще забыли, это так странно с учётом того что у всех не-федоровцев и владельцев процессоров без SSE4.1 было старое, примитивное, поведение memcpy.
man memcpy.
Безусловно Дреппер тогда вёл себя не корректно, но он был прав.
Разве что с точки зрения эгоистичного задрота: стандарт ведь не *обязывал* его делать поведение memcpy() непредсказуемым, но он всё же сделал. Иначе говоря, для него чистота его кода важнее, чем удобство пользователя. Код ради кода. Я против такого подхода точно так же, как и против говнокода.
Вызвать на комсомольский суд чести.
Вынести общественное порицание за недостаточное боление душой за нужды простых программистов.
Лишить путевки в санаторий.
буэ
А ты кто такой?
Паниковский, залогиньтесь.
> А ты кто такой?Судья, кто ж ещё. Вон как раскидал, и про эгоистов, и про зaдрoтов.
У него моральнiй компас
Тварь он продажная, этого бага не было на новых процах от Интеля, потому как юзало SSE4.
А фотографию дачи, которую он построил на нетрудовые доходы?
> новыхСтарых. И на всех AMD, ARM и т.д.
Ядро слишком большое чтобы его форкать (кому-то кроме Гугла).
История с XEmacs и периодические историйки с мелкими гну-софтами.
> Торвальдс, Столман - они другие?Когда как. С Торвальдсом вполне можно решить большинство вопросов. Если нормально аргументировать свою точку зрения и это не будет бредом.
> В их храме тоже хрен в алтарь на--рёшь.
Тю, вон одни в храме всего лишь ногами подрыгать решили - так им 2 года кутузки выдали. А в твоем случае - спасибо скажешь, если не расстреляют. А то смотри, Linux нынче и на винтовках бывает...
> не перенесены в GLibc: ... динамическая перезагрузка /etc/resolv.confОй, а теперь придется это учитывать. А было удобно. :(
А есть уверенность что дебианщики не налепят свой патч?
Я хоть и программист (прикладной правда), но разницу не замечу.
Впрочем, чем ближе к "корням" -- тем лучше. Нехорошо когда проекты масштаба Дебиан используют ключевые инструменты, поставляемые "группой энтузиастов, отвечающих на слишком жесткую и централизованно контролируемую политику".
> Нехорошо когда проекты масштаба Дебиан используют ключевые инструменты, поставляемые "группой энтузиастов, отвечающих на слишком жесткую и централизованно контролируемую политику".Спорно. Мне казалось, что само явление GNU - в некотором роде ответ "энтузиастов на жесткую централизованно контроллируемую политику".
>Спорно. Мне казалось, что само явление GNU - в некотором роде ответ "энтузиастов на жесткую централизованно контроллируемую политику".И не поспоришь. Ядро тому самый яркий пример. Никакой централизованной политики и тоталитаризма, чистая демокрвтия.
>>Спорно. Мне казалось, что само явление GNU - в некотором роде ответ "энтузиастов на жесткую централизованно контроллируемую политику".
> И не поспоришь. Ядро тому самый яркий пример. Никакой централизованной политики и
> тоталитаризма, чистая демокрвтия.Ядро Linux разве проект GNU?
По сути всё что под лицензией GPL - это GNU. А входит ли в официальный набор - это уже формальности.
Не порите чушь, ей больно. (ц)
Вас не устраивает политика принятия изменений в ядро операционной системы GNU - HURD?
> Ядро тому самый яркий пример. Никакой централизованной политики и
> тоталитаризма, чистая демокрвтия.Наглядно видны достоинства демократии.
При демократии в ядре уже были бы Qt с Weyland от Windows оно бы отличалось только названием.
Ну, KMS благополучно возник, несмотря на то, что ещё десять лет назад работа с графикой полностью из юзерспейса преподносилась как великое благо, в отличие от "венды, у которой гуй в ядре и поэтому она такая нестабильная".
Никто и не говорил что разница - принципиальная.
Только то что скорость скатывания в добро при демократии - максимальная.
> Ну, KMS благополучно возник, несмотря на то, что ещё десять лет назад работа с графикой полностью из юзерспейса преподносилась как великое благо, в отличие от "венды, у которой гуй в ядре и поэтому она такая нестабильная".Справедливости ради можно отметить, что в Linux ядро занимается только самой низкоуровневой частью графической подсистемы -- ставит разрешение экрана и, ЕМНИП, предоставляет буфер юзерспейсу. В винде же частью ядра являются даже некоторые функции работы с окнами (только в прошлом году они удосужились исправить баг, позволявший повалить систему в BSOD всего одним вызовом функции изменения размеров окна).
> Ну, KMS благополучно возник,При том делает простые и низкоуровневые операции, которые явно в компетенции ядра. Типа переключения режимов и управления памятью. А что, памятью юзермод чтоли должен управлять? Да это бред, в остальных случаях памятью ядро управляет.
>> Ядро тому самый яркий пример. Никакой централизованной политики и
>> тоталитаризма, чистая демокрвтия.
> Наглядно видны достоинства демократии.
> При демократии в ядре уже были бы Qt с Weyland от Windows
> оно бы отличалось только названием.Вы уже определитесь - или трусы наденьте, или галстук снимите. То сначала говорят что им тоталитаризм не нравится, они свой libc с блэкджеком запилят, то теперь им это благо, обуздайте нас скорее.
А вы не мешайте всё в одну кучу.
Пусть цветут 100 разных тоталитаризмов, а мы, пользуясь открытостью границ, будем между ними выбирать.
Зачем же так жёстко ограничивать? Пусть будет всё и свобода выбора из этого всего + костыле, чтобы всё не умерало. А то так, выживет только наиболее приспособленный, а не наиболее годный.
> И не поспоришь. Ядро тому самый яркий пример. Никакой централизованной политики и
> тоталитаризма, чистая демокрвтия.Абсолютно. Git clone - и художествуй как хочешь. А то что Товральдс твой патч вовсе не обязан принимать - так у него тоже есть свободы. Например, свобода посылать тебя в пешее эротическое путешествие.
Ждем новость "после тщательного, напряженного обдумывания вопроса убунтятами принято волевое решение перейти на glibc, слава инновациям, Марк слава!".
> Ждем новость "после тщательного, напряженного обдумывания вопроса убунтятами принято
> волевое решение перейти на glibc, слава инновациям, Марк слава!".А зачем Марку быть святее папы римского? Да еще за свой счет?
Идущие на systemd приветствуют Марка.
кому че, а лысому расчестка... везде убунту приплетут
> кому че, а лысому расчестка... везде убунту приплетутЧерный пиар - тоже пиар :).
слабаки :)
Stop reopening the bug..
Предвкушаем заголовки новостей "Debian возвращается с системд на сис-инит" (по словам парам-пам-пам яростно развиваемый проект системд уже никому не нужен, и стал не перспективным)
На sysvinit никто возвращаться не будет, устарел-с.Ждём openrc по умолчанию.
> На sysvinit никто возвращаться не будет, устарел-с.
> Ждём openrc по умолчанию.У Debian свой sysvinit, параллельный, с блекджеком :)
> У Debian свой sysvinit, параллельный, с блекджеком :)Да, и их задолбало велосипедить и они таки тоже решили валить на systemd :).
> динамическая перезагрузка /etc/resolv.confНе думал что поддержка TCP/IP в Linux так глубоко - аж в Glibc. Хакеры, ответьте на вопрос. Будет ли работать система, если на первом экране make menuconfig ядра Linux снять галочку поддержки сети? Если нет - в какой момент система работать перестала? В 2.6, в 2.4?
Казалось бы, причем тут TCP/IP и DNS? Не путаешь теплое с мягким?
>Не думал что поддержка TCP/IP в Linux так глубоко - аж в Glibc.Во-первых не так уж и глубоко - в библиотеке. Во-вторых - это не поддержка TCP/IP, а реализация одного часто используемого клиента (DNS).
В-третьих, поддержка TCP/IP еще глубже - в ядре.
> Не думал что поддержка TCP/IP в Linux так глубоко - аж в Glibc.Обломись, glibc - умная обертка к услугам ядра, не более.
> Хакеры, ответьте на вопрос. Будет ли работать система, если на
> первом экране make menuconfig ядра Linux снять галочку поддержки сети?Сети не будет. А что ты ожидал, отключая сеть? А работать скорее всего будет. Ну работает же система если нет никаких сетевых подключений. А плюс-минус тот или иной драйвер - уже весьма вторичный вопрос.
> Обломись, glibc - умная обертка к услугам ядра, не более.Математические функции тоже в ядро и обратно "гоняют"? Верую!
Интересно, когда разработчики libav одумаются, и так-же поступят по мужски - признают что они пилят велосипед, и вернуться под крыло более прогрессивного ffmpeg.
> Интересно, когда разработчики libav одумаются, и так-же поступят по мужски - признают
> что они пилят велосипед, и вернуться под крыло более прогрессивного ffmpeg.Справедливости ради, в ffmpeg тоже хватает граблей, которые выпилили в libav.
> Справедливости ради, в ffmpeg тоже хватает граблей, которые выпилили в libav....и создают 100500 новых граблей. Спору нет, свои грабли лучше чем чужие. Ибо NIH синдром же!
>> Справедливости ради, в ffmpeg тоже хватает граблей, которые выпилили в libav.
> ...и создают 100500 новых граблей. Спору нет, свои грабли лучше чем чужие.
> Ибо NIH синдром же!вся суть опеннет-долб...анонима в одной фразе - обилие штампов, собственное выдумывание фактов, подача материала. По-моему, этот комментарий можно ставить к АБСОЛЮТНО ЛЮБОЙ НОВОСТИ, и облегчить их анонимам их анонимский труд, пусть отдыхают...
Вышел CouchDB 1.6?> ...и создают 100500 новых граблей. Спору нет, свои грабли лучше чем чужие.
> Ибо NIH синдром же!Портирование ос на калькуляторы
> ...и создают 100500 новых граблей. Спору нет, свои грабли лучше чем чужие.
> Ибо NIH синдром же!в общем, этот комментарий везде уместен. потому что везде одинаково неуместен. :)
> Интересно, когда разработчики libav одумаются, и так-же поступят по мужски - признают
> что они пилят велосипед, и вернуться под крыло более прогрессивного ffmpeg.Очевидно же, после ритуального сепуку ментейнеров второго.