Debian переходит на EGLIBC

Патрик одобряет? Нужно этот огород на слаку городить?

Новости от AEP неизменно радуют.

А Ulrich Drepper тот еще отморозок. Ржу.

Хм.. а чем uClibc и Newlib не угодили? Нужно бы почитать...

> а чем uClibc и Newlib не угодили?

бинарной несовместимостью с GLIBC => невозможностью использования заранее скомпилированного софта и сертификации по LSB

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

Хм, переходит ВЕСЬ Debian, или только *embedded*-ориентированные?

весело? когда в тестинг выкинут?

>бинарной несовместимостью с GLIBC => невозможностью использования заранее скомпилированного софта и сертификации по LSB

Т.е. uClibc и Newlib сертифицированы по LSB?

А пока, сегодня благополучно обновился libc6 до версии 2.9-10

И переход на gcc-4.4 в базе не завершен пока.

> А Ulrich Drepper тот еще отморозок. Ржу.

Я это понял еще тогда, когда он Майкла Микса с патчем -Bdirect опускал по поводу «пшелнахунасестьprelink», даже не разобравшись в предмете.

> Хм, переходит ВЕСЬ Debian, или только *embedded*-ориентированные?

Я так понял что весь (начиная с unstable с постепенным уходом в stable). Поддержка встраиваемых устройств и незацикленность на bash это одни из многих улучшений в сравнении с glibc

Когда я тестил ulibc он вообще на libc мало подходил. Половину программ надо было патчить для работы с ним, остальные жутко глючили.

теперь осталось остальные дистрибутивы перевести и забыть про glibc вообще

>Я так понял что весь (начиная с unstable с постепенным уходом в stable). Поддержка встраиваемых устройств и незацикленность на bash это одни из многих улучшений в сравнении с glibc

Ждём более сильных тормозов от системы.

>теперь осталось остальные дистрибутивы перевести и забыть про glibc вообще

Учитывая, что редхатовцы пишут glibc - такой исход малореален. привет, Ульрих Дреппер, ага..

Так бубунта похоже тоже перейдет?

Я не знаю какой тут профит будет лично для меня, но ребята однозначно молодцы!

Подход к написанию GNU libc радует.

>------- Additional Comment #10 From Ulrich Drepper 2007-12-14 03:52 [reply] -------

>>Stop reopening the bug. If you want explanations pay somebody.

Взято тут http://sourceware.org/bugzilla/show_bug.cgi?id=4980

>>теперь осталось остальные дистрибутивы перевести и забыть про glibc вообще

>Учитывая, что редхатовцы пишут glibc - такой исход малореален. привет, Ульрих Дреппер, ага..

Так eglibc базируется на glibc. Похоже, это просто glibc с более навороченным скриптом configure, грубо говоря. Так что про забыть сильно погорячились.

>теперь осталось остальные дистрибутивы перевести и забыть про glibc вообще

Он так плох?

>Ждём более сильных тормозов от системы.

почему не нашествия инопланетян? лишь бы что написать неразобравшись в теме?

В дебиане баш все равно нельзя удалить и поставить zsh например. Идиоты в скриптах жестко зашили /bin/bash

> В дебиане баш все равно нельзя удалить и поставить zsh например.

Кмк, вполне можно поставить zsh в качестве /bin/sh, и все будет работать.

> Идиоты в скриптах жестко зашили /bin/bash

В тех скриптах, которые пользуются bash-измами. Единственная альтернатива - переписывание скриптов под posix sh - не везде легко осуществима.

1. Оставляешь bash в системе
2. Ставишь своим шеллом zsh
2. Делаешь /bin/sh -> dash
3. ?????
4. ПРОФИТ

Вообще то ты сказочку сильно подсократил ))

Ульрих ответил в первом же посте.

> ------- Additional Comment #3 From Ulrich Drepper 2007-09-23 16:07 [reply] -------
> Stop reopening bugs. Search the web if you want an explanation ...

Так что происхождение 10-ого объяснимо ))

>Более полный набор тестов для оптимизированных пакетов и для поддержки двух архитектур одновременно (i386/amd64)

Чем это поможет debian-arm, debian-mips, debian-etc?

>почему не нашествия инопланетян? лишь бы что написать неразобравшись в теме?

Может потому, что оно собирается по умолчанию с -Os?

>Может потому, что оно собирается по умолчанию с -Os?

кто же из пакетов дебиан собирает с ./configure без параметров? ^^

Я думаю что будет 2 бинарных пакета, один с -Os (для всяких разных livecd) и обычный (-O2 ?)

Отлично. Дебиан двигается вперед. Рад за него.

>Ульрих ответил в первом же посте.

>LamerOk (06.05.2009 13:38:59)

Послать в гугл - это не всегда ответ =). Объяснить причину такого поведения GLIBC он так и не соизволил.

Несмотря на то, что ему даже заплатили (1$), как он и просил (сам сумму необходимую он не уточнил =) ).

Его попросили объяснить причину хотя бы в комментах в коде или в комментах к коммиту или в обсуждении. Фиг.

>Взято тут http://sourceware.org/bugzilla/show_bug.cgi?id=4980

Ulrich, В этой ветке, абсолютно прав! А долбодятлы всякие, какой только хрени, в баглист не суют. Идиоты недоделаные.

>Объяснить причину такого поведения GLIBC он так и не соизволил.

Мля, ещё один долбодятел... RTFM ! Кури RFC !

прозреваю волну холиворов EGLIBC vs GLIBC :)

> Взято тут http://sourceware.org/bugzilla/show_bug.cgi?id=4980

Вот спасибо за ссылку, повеселил :)

Рекомендую всем ознакомиться. Лорквотесы отдыхают :)

> Объяснить причину такого поведения GLIBC он так и не соизволил.

Не всё можно объяснить в одном абзаце, а багзилла - не форум.

Хотя дисскусия там вполне под стать нашим лоровским срачам )))

>Хотя дисскусия там вполне под стать нашим лоровским срачам )))

Ульрих троллит по черному

как бы... совместимость с убунтой пропадает?

> Разработчики не закрывают правильные сообщения об ошибках как WONTFIX

EGLIBC - это месть ленивым разработчикам GLIBC

> Хотя дисскусия там вполне под стать нашим лоровским срачам )))

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

<таг>бросаю курить</таг>

> например, можно удалить возможность разрешения имен через NIS из libc для инсталляционного диска

ЩИТО?

> Вот спасибо за ссылку, повеселил :)

Страничка http://blog.aurel32.net/?p=47 битком-набита ссылками на другие креативы Ульриха.

Поздравляю всех с дебианкапцом!

И нафига это рядовым пользователям, на рабочих станциях, серверах?

http://www.eglibc.org/faq

>EGLIBC is not meant to be a fork of GLIBC. GLIBC is well-suited to its core mission: providing a C library for use on workstation and server GNU/Linux systems. However, the GLIBC developers have requirements that make GLIBC difficult to use on embedded systems. The goal of EGLIBC is to provide a variant of GLIBC for use on embedded systems, but with as few changes to GLIBC as possible.


>First and foremost, uClibc is available today, and is already shipping on a large number of systems. EGLIBC is a new project. If you need a small C library today, uClibc is a better choice. The following paragraphs refer to the goals for EGLIBC, not its current state.

Вобщем надеюсь они знают, что делают, главное чтобы не поломали все.

Православная новость :}

> Поздравляю всех с дебианкапцом!

Сначала вместе с Роботроном тормозов дождитесь.

>Поздравляю всех с дебианкапцом!

Ололо! Дебиан вас всех еще продаст и купит. Потом снова продаст, но уже дороже ))))

Долго ли они собираются поддерживать 100% совместимость?

>Поддержка сборки с /bin/sh != bash

А оно так надо? Ну, только если есть любители zsh

Вон, во FreeBSD по умолчанию не шелл, а убожество, первым делом из портов ставил bash и прописывал его по умолчанию..