Организация Linux Foundation представила (http://www.linuxfoundation.org/news-media/announcements/2011...) релиз Yocto 1.1 (http://www.yoctoproject.org/), платформы для создания встраиваемых Linux-систем для различных аппаратных архитектур. Yocto сам по себе не является дистрибутивом, но предоставляет набор компонентов для создания собственных дистрибутивов для встраиваемых продуктов на базе таких аппаратных архитектур (http://yoctoproject.org/projects/hardware-support), как ARM, PPC, MIPS, x86 и x86-64. В состав платформы входит инструментарий разработчика, система сборки, набор программных интерфейсов и коллекция мета-пакетов.Одновременно с анонсом новой версии платформы объявлено о том, что отныне разработка системной библиотеки EGLIBC (http://www.eglibc.org/) (Embedded GLIBC) будет вестись в рамках проекта Yocto, под покровительством Linux Foundation. Ранее разработкой EGLIBC управляла компания Mentor Graphics, развивающая проект при уч...
URL: http://www.linuxfoundation.org/news-media/announcements/2011...
Новость: http://www.opennet.me/opennews/art.shtml?num=32137
Йоцто мало интересует, а вот по eGlibc встал вопрос. Написано:> Проект EGLIBC развивается с целью использования на встраиваемых
> системах и отличается значительно более низкими системными требованиями,
> возможностью гибкой настройки компонентов, улучшенной поддержкой
> кросс-компиляции и кросс-тестирования.А оно подходит в качестве замены кошерному Glibc на обычных, не-встроенных, системах? Или есть какой-то подвох?
Судя по wiki (http://en.wikipedia.org/wiki/Eglibc) Debian использует eglibc ещё с 2009го года. Они просто старое название оставили, а сорцы от eglibc используют.
> Debian использует eglibc ещё с 2009го года. Они просто старое название оставили, а сорцы от eglibc используют.Дело не только в названии. Используемая в Большом Дебиане eglibc абсолютно идентична glibc.
Разница начинается в его embedded-форках, в частности, в emdebian. Собственно, для упрощения совместимости с ними, дебиан и перешел на eglibc.
уже многи дистры используют. Дебиан например.
>А оно подходит в качестве замены кошерному Glibc на обычных, не-встроенных, системах?Используется в Debian, уже довольно давно.
Eglibc это просто новая система сборки для glibc. Т.е. не замена и не форк, а тот же glibc, только собранный по другому. Дебианщикам это зачем-то понадобилось, возможно, из-за обилия архитектур, которые они поддерживают, поэтому, они и запилили свою систему сборки для glibc.
> Дебианщикам это зачем-то понадобилось, возможно, из-за обилия архитектур, которые они поддерживают, поэтому, они и запилили свою систему сборки для glibc.Говорят, их товарищи из Emdebian упросили, для упрощения унификации.
> Eglibc это просто новая система сборки для glibc. Т.е. не замена и
> не форк, а тот же glibc, только собранный по другому.На их сайте написано что-то типа "мы не форк, а набор патчей к". Скромничают-шифруются...
> Дебианщикам это зачем-то понадобилось, возможно, из-за обилия архитектур, которые они поддерживают,
* More friendly upstream ...
* Stable branch with fixes for important bugs ...
* Better support for embedded architectures.
* Support for different shells (GLIBC only supports bash).
* Support for building with -Os.
* Configurable components ...
* Better testsuite for optimized or biarch packages.
http://blog.aurel32.net/?p=47Короче, Ульрих Дреппер получил вотум недоверия. Какие там "системы сборки" -- мелочи это... И да, ни eglibc-исты, ни дебианнеры _так эти события _старательно не трактуют.
> поэтому, они и запилили свою систему сборки для glibc.
AFAIR, eglibc был создан не в Debian, но D. им воспользовался, потому что тот ему "подошёл", и теперь сам факт использования eglibc-а Debian-ом imho несколько затмевает (хотяб по пиару, как бы это ни странно смотрелось в контексте D.) все прочие его use case-ы. Сугубо субъективно, конечно.
> Короче, Ульрих Дреппер получил вотум недоверия. Какие там "системы сборки" -- мелочи
> это... И да, ни eglibc-исты, ни дебианнеры _так эти события _старательно
> не трактуют.Вы, блин, хотя бы тег <ирония> ставьте, а то я чуть чаем из-за вас не поперхнулся :-\
> Вы, блин, хотя бы тег <ирония> ставьте, а то я чуть чаем
> из-за вас не поперхнулся :-\А при чем тут ирония? Вы посмотрите на сообщения Дреппера например в багтрекерах. И подумайте: стали бы вы взаимодействовать с таким "less friendly upstream"? Поэтому, "благодаря Дрепперу, почти все дистрибутивы Linux форкают glibc, но не все признаются в этом" (уже не помню кому принадлежит эта фраза, знаю лишь что она старая).
> Вы посмотрите на сообщения Дреппера например в багтрекерах.Дааа. Ульрих красавчик, почти как Линус
Idiot. There is no bug. Don't reopen. (это как раз по поводу IPv6 localhost).
Что касается якобы "нарушения RFC", то этим дурикам все подробно разжевали http://sourceware.org/bugzilla/show_bug.cgi?id=4980#c25
Но читать они не умеют, очевидно.> стали бы вы взаимодействовать с таким "less friendly upstream"
А вы по ссылке ходили? Открою вам страшную тайну: там дальше написано
> More friendly upstream (especially with regard to embedded architectures)В задачу Дреппера не входит создание "колбасной нарезки" с возможностью частичного выкидывания функциональности. Собственно, эта задача с успехом решается eglibc.
> "благодаря Дрепперу, почти все дистрибутивы Linux форкают glibc, но не все признаются в этом" (уже не помню кому принадлежит эта фраза, знаю лишь что она старая)
linux-image форкают чаще и масштабнее :)
Да и большинство других приложений не избегают этой участи. Это называется "поддержка" и "интеграция".
Да там(http://sourceware.org/bugzilla/show_bug.cgi?id=4980#c25) стеб в чистом виде, народ так глумится вы чЁ?
> Вы посмотрите на сообщения Дреппера например в багтрекерах.да, он не любит дураков. и не стесняется говорить дуракам, что они дураки. вполне разумный подход. а то дураки отчего-то начали считать, что они обладают такими же правами, как и умные — а это не так.
> А оно подходит в качестве замены кошерному Glibc на обычных, не-встроенных, системах?
> Или есть какой-то подвох?Подвох состоит в том, что на обычных, не-встроенных системах eglibc полностью идентична glibc.
> Подвох состоит в том, что на обычных, не-встроенных системах eglibc полностью идентична
> glibc.Потому что основная задача eglibc - предоставить возможность выкидывания той или иной функциональности glibc на этапе сборки. Для ембеддовки - возможность очень полезная, для десктопов - нафиг не сдалось, им проще и удобнее полноценную glibc собрать (eglibc и это позволяет).
Благодарствую. Понял.
>> А оно подходит в качестве замены кошерному Glibc на обычных, не-встроенных, системах?
>> Или есть какой-то подвох?
> Подвох состоит в том, что на обычных, не-встроенных системах eglibc полностью идентична
> glibc.А на встроенных?
> А на встроенных?А на встроенных, очевидно, будут отличаться. eglibc позволяет собрать glibc без некоторых компонентов, которые для данной конкретной задачи не нужны. Выбор этих компонент - на усмотрение сборщика.
Других изменений (в частности, нарушение совместимости работы присутствующих компонентов) eglibc не вносит, они же не враги своему здоровью. glibc может быть только одна.
После шквала новостей про скандалы из-за потери совместимости в glibc в этом году, я рад, что есть форк
> что есть форкЭто не форк.
> Это не форк.Вам бы так хотелось думать, а на самом деле см http://www.opennet.me/openforum/vsluhforumID3/81007.html#25
> Вам бы так хотелось думать, а на самом деле кококоЧто сказать-то хотели?
И не было никакого шквала, как и потери совместимости.
> И не было никакого шквала, как и потери совместимости.Ну был там небольшой микроскандальчик, когда пара хомячков грозно попищала на Дреппера, а потом его еще Линус на этой почве троллил :)
Это еще когда флеш, работавший через баг в glibc, перестал работать, когда этот баг пофиксили. С точки зрения Zenitur-like hamsters, адобе - молодцы и святые, а во всем виноват злой Дреппер.
смеялсоЖаль, что ваш (да и мой) пост наверняка потрут модеры за неполиткорректность. Хотя по существу написано как раз все верно, в отличие от странного поста Zenitur.
> Ну был там небольшой микроскандальчик,Уточним, Ульриха почему-то подозрительно окружают такие микроскандальчики. Адоба всего лишь продолжение общей тенденции. Аналогичная история была например с резольвом имен и IPv6, когда очередные изменения ведущие к одному ульриху ведомому выигрышу как всегда положили несколько крупных энтерпрайзов и админы прибежали бить челом в багтрекер шапки. А там ульрих, традиционно объясняющий: "just as planned". Ради чего и в чем WIN - как всегда объясняется грубым закрытием тикета. Попытки тыкания в нарушения RFCов - аналогично. Вот и возникла нужда в "more friendly upstream".
> Уточним, Ульриха почему-то подозрительно окружают такие микроскандальчики. Адоба всего
> лишь продолжение общей тенденции. Аналогичная история была например с резольвом имен
> и IPv6, когда очередные изменения ведущие к одному ульриху ведомому выигрышу
> как всегда положили несколько крупных энтерпрайзов и админы прибежали бить челом
> в багтрекер шапки.На что Ульрих им ответил "stop defending broken code" и был абсолютно прав.
Если OpenLDAP глючит из-за бага в OpenLDAP (ах, он не знает, что одно имя может резолвиться на несколько айпишников), это должно лечиться явно не наворачиванием костылей в libc.Интересно, почему эти доблестные защитнички еще в багзиллу BIND не написали, что нехорошо по нескольку А-записей возвращать?
> Попытки тыкания в нарушения RFCов - аналогично.
Которые на практике оказались полным незнанием предмета обсуждения. IN6_IS_ADDR_V4COMPAT( ::1 ) = false, хотя борцуны с Дреппером утверждали обратное.
> Вот и возникла нужда в "more friendly upstream".
... especially with regard to embedded architectures. Правда, как это связано - непонятно.
> ... especially with regard to embedded architectures. Правда, как это связано -
> непонятно.В смысле, непонятно, как это связано с хомячьими наездами на Дреппера. Хомячки от него отнюдь не эмбеддовских фич требовали, а костылей для совместимости с кривым софтом.
> Уточним, Ульриха почему-то подозрительно окружают такие микроскандальчики.потому что он умеет читать документацию, а обезьяны — нет. зато обезьяны умеют громко и глупо орать.
> И не было никакого шквала, как и потери совместимости.Был. Вот примеры: http://avva.livejournal.com/2323823.html http://ipdemon.ru/2011/04/vmware-centod55-error-glibc/
Баян! Вот еще немного Скандалов Интриг и Расследований http://lists.fedoraproject.org/pipermail/devel/2011-October/.... Вкратце, федоровцы начали таки чтото подозревать и хотя последняя оптимизация в glibc очень даже полезная, но возникли сложности с многопоточными программами и пришлось пакеты заново собирать, насмотря на то что релиз уже скоро. В другом треде прошлись немного по порочной практике вносить изменения в glibc как раз за пару недель до релиза.
то, что авва — тупица и дегенерат, это, кагбэ, не секрет. но какое это имеет отношение к Ульриху и glibc?
я плакать. мусье даже не в курсе просто.
> я плакать. мусье даже не в курсе просто.Мусье в курсе, мусье все знает! Что в Adobe - молодцы и гении, и они всегда все делают правильно и единственно верно, даже если их продукция работает исключительно при наличии багов в системной библиотеке. А злобный дядька Дреппер, который настолько обнаглел, что исправляет баги во вверенном ему проекте, тем самым ломая работу показывалки рекламы от Самой Лучшей Софтовой Компании - просто подлец и мерзавец.
иногда лучше оставить работающий дефакто стандарт.
такая же ситуация была когда некто "починил" tty подсистему в ядре - и много чего поломалось.
> такая же ситуация была когда некто "починил" tty подсистему в ядре -
> и много чего поломалось.Да что там, помнится Ульрих чинил резольв имен. В результате починки - ну подумаешь, RFC нарушил, подумаешь несколько больших энтерпрайзов завалил, подумаешь закрыл десяток раз баг под грохот кирпичей из задниц админов у которых все на ровном месте упало, под их дружные маты и переоткрытия тикетов. Действиьельно, ведь ульрих бох, ему все можно, да?
> Да что там, помнится Ульрих чинил резольв имен. В результате починки -
> ну подумаешь, RFC нарушил,Якобы имевшее место нарушение RFC никто так и не смог внятно обосновать.
> подумаешь несколько больших энтерпрайзов завалил, подумаешь
> закрыл десяток раз баг под грохот кирпичей из задниц админов у
> которых все на ровном месте упалоА в кривизне "энтерпрайзного" софта, который падает от нескольких айпишников на одном доменном имени, почему-то виноват Ульрих, да.
Если я в hosts два раза напишу "127.0.0.1 localhost", то этот энтерпрайзный глюкодром все равно грохнется, даже безо всякой помощи Ульриха. Но виноват в этом, конечно же, будет он.
> ну подумаешь, RFC нарушила теперь неси сюда пруфы нарушений, гребнеголовый.
> иногда лучше оставить работающий дефакто стандарт.Типа, наша библиотека в результате сложения 2 и 2 выдает 5, и чинить мы это не будем, потому что это новый стандарт в математике.
> такая же ситуация была когда некто "починил" tty подсистему в ядре -
> и много чего поломалось.Не вижу ничего общего. Кривой патч привел к серьезной ошибке внутри самого ядра. Для glibc ничего похожего не приводилось.
> Мусье в курсе, мусье все знает! Что в Adobe - молодцы и
> гении, и они всегда все делают правильно и единственно верно,Так случай с адобой не единственный, когда все поломали, выигрыш неочевиден, а зато побочные эффекты раздают на орехи половине пользователей и администраторов. Это стандартная политика этого апстрима - класть на своих пользователей/даунстримов и куролесить по своему, вплоть до игнорирования RFC.
> вплоть до игнорирования RFC.Ну сколько можно этот бред повторять? Вся суть претензий сводилась к тому, что IN6_IS_ADDR_V4COMPAT для "::1" якобы выдает true. Но по любой дурак может скопилировать простенькую демку http://sourceware.org/bugzilla/attachment.cgi?id=2816 и убедиться, что он выдает false.
Доблестные борцуны с нарушениями RFC даже компилятор запустить не осилили, а все туда же - указывают, как правильно код писать.
перефразирую классику: "ошибка в программе должна быть исправлена"
> перефразирую классику: "ошибка в программе должна быть исправлена"На практике, существуют два разных подхода. В контексте данного обсуждения их можно назвать "подход Дреппера" (ошибка должна быть исправлена) и "подход противников Дреппера" (ошибочное поведение должно быть объявлено новым стандартом).
> "подход противников Дреппера" (ошибочное поведение должно быть объявлено новым стандартом).Кстати напомнило бородатый анекдот:
- Сколько программистов Microsoft нужно, чтобы поменять лампочку?
- Ни одного. Темнота будет объявлена новым стандартом.
второй подход известен больше под фразой "it's not a bug it's a feature"?
второй подход известен под фразой "совместимость в первую очередь"
есть разные решения таких проблем. реже - когда приходится выбирать: или закрыть потенциальную дыру, либо оставить совместимость. а разве в таком случае ответ не однозначен?
> есть разные решения таких проблем. реже - когда приходится выбирать: или закрыть
> потенциальную дыру, либо оставить совместимость. а разве в таком случае ответ
> не однозначен?Неоднозначен согласен.
Однако например в memcpy споре минусов от сохранения старого поведения фактически не было, но Дреппер всё равно бодался до последнего и называл всех ламерами ;-)
темпераментные люди тоже бывают. а бывают и те, которые не знают и тянут одеяло на себя ввиду каких-то там присутсвующих комплексов. с Ульрихом лично не знаком, сказать не могу, что он там из себя как личность представляет.
единственное, memcpy и т.п. не такая уж простая тема, как кажется. при больших размерах важна оптимизация, а значит фактически она должна использовать максимальные возможности из предоставленной железки :)
> второй подход известен под фразой "совместимость в первую очередь"и это совершенно идиотичный подход. fix the bug, recompile the code. что? а-а-а, нет исходников, не выходит починить? ну, сосите лапу, чо. или пишите в саппорт вашего вендора, пусть он чинит своё поделие.
ну это же классика жанра, в стиле m$. положить батон на пользователей, а программеры настроят костылей уж как-нибудь ;)
> ну это же классика жанра, в стиле m$. положить батон на пользователей,
> а программеры настроят костылей уж как-нибудь ;)ORLY? а может, это как раз нечто, *отличное* от m$: отказ поддерживать совместимость с *багами*? баги должны правиться. period. встраивание костылей для забагованых програм — порочная практика. period.
пользователи спокойно идут в багтрекер и говорят там, что баг есть. авторы правят баг. пользователи обновляют софт. все довольны. если авторы тормозят, патч делает кто-то другой, он всё равно попадает в репы, пользователи обновляют софт… и так далее.
а то, что у проприетарщиков большие проблемы со скоростью реагирования — совершенно не является причиной делать для них костыли. nothing personal, как они любят говорить: пусть подстраиваются.
RLY. речь идет не о поддержке сторонних глючных программ этой конторой.
клиенты m$ пишут о баге в драйвере звуковухи, отсылают крэшдампы. указывают конкретную либу - в которой не производится освобождение памяти. после этого m$ молчат месяца три, как рыба об лёд, а потом начинают нелепо отмазываться по поводу того, что драйвер не наш и проблема не наша. но дело в том, что драйвер сей поставлялся на стандартной установочной CD и даже копирайты на либе майкросовстовские красуются. вот такие вот нонсенсы поддержки.пусть подстраиваются - как раз стиль работы m$
все последующие проекты после этого случая, переполнившего чашу терпения моих коллег, стали базировать на дебиане. благо переход не сильно болезненно прошёл.
и к чему был этот поток сознания?
к вашему "ORLY?"
> из-за потери совместимости в glibc«совместимость» с программами, написаными криворукими обезьянами, не нужна. fix your bad code, такие дела.