glibc 2.5

OK. Ясно.. ;-)

ТОлько недавно же 2.4 вышла, у них цикл менее полугода чтоли?

Кто первее соберет? :)

>ТОлько недавно же 2.4 вышла, у них цикл менее полугода чтоли?

присоединяюсь к вопросу, версии 2.4.1 даж не было =(

Дык небось это нестабильная ветка, не?

> getaddrinfo теперь приведет в соответствии с RFC 3484

кто кого куда приведёт???

> кто кого куда приведёт???
Это приведёт к капцу венды. По-любому.

>Дык небось это нестабильная ветка, не?

сомневаюсь, потому как 2.3 - была стабильной веткой

>/etc/gai.conf

Улыбнуло.

> настройка getaddrinfo в файле /etc/gai.conf

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

зы: и выписать штрав докучи. man gai_strerror

зыы: винде капец. %)

> > ТОлько недавно же 2.4 вышла, у них цикл менее полугода чтоли?

> присоединяюсь к вопросу, версии 2.4.1 даж не было =(

В ядре 2.6.17 появились упомянутые системные вызовы (tee, splice и пр.), о которых разработчики glibc "давно мечтали" (цитата времён выхода 2.6.17). Понятно, что добавление системных вызовов - крупный шаг, так что реализовывать их поддержку в 2.4.1 было бы глупо, вот и выпустили новую версию.

>gai.conf

ахтунг!

> новый формат ELF hash table

Значит ли это, что проги, скомпилированные с новым glibc, будут быстрее запускаться?

Значит ли это, что новый glibc не совместим со старыми?

Все это конечно здорово - но обещанную стабильную 2.3.7 мы так и не получили. А это свинство, господа.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/posix/gai.conf?r...

Какой ужас...

> Значит ли это, что проги, скомпилированные с новым glibc, будут быстрее запускаться?

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

> Значит ли это, что новый glibc не совместим со старыми?

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

Т.е. несовместимости от факта выхода еще нет, но дистростроители через пол-годика-годик создадут ее в полной мере.. Те, кто не перейдут на новый glibc, будут иметь проблемы с прогами для более прогрессивных дистрибутивов.. Чую, в debian ubunt'овские проги скоро пахать не будут..

Так будет ли 2.4.1?

З.ы. а что никто не ждет ебилдов?, или ждете сначала смены опроса? :D

На ебилды нам пофиг, а для гентушнегов - вполне прокатят от 2.4 ;)

Странно, что 2.4 даже не в unstable, может ждали 2.5? =)

Странно - выходной вроде

Чего это они?

ИМХО, главная новость - это поддержка priority-inheritance futex.

А линковка через хэш-таблицу, это то, что хотели опеноффисовцы?

> А линковка через хэш-таблицу, это то, что хотели опеноффисовцы?

Им уже ничто не поможет...

А почитать про новую hash table где можно?

В выводе командочки `cvs log`.

Кстати, к слову, о птичках... она таки __stable__ :

-GNU C Library development release version 2.4, by Roland McGrath et al. +GNU C Library stable release version 2.5, by Roland McGrath et al.

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

> Дык небось это нестабильная ветка, не?

Все ништяк, стабля. Теперь осталось понять - релиз 11-й слаки будет отложен, или таки нет.

Вряд ли. Патрик консератор. (За что ему и спасибо: и система стабильная, и опыта набираешься, пока со стабильностью этой борешься :-) )

> и опыта набираешься, пока со стабильностью этой борешься :-) )
Не, опыта мало, пионеры уже всё разузнают и раскажут, остается только повторять за ними =)

мне интересно будет ли она бинарно совместима с 2.4

> мне интересно будет ли она бинарно совместима с 2.4

Ну да.. В glibc 2.4-based федорке поставил 2.5 из следующей версии - все пашет как часы. Ничего не сломалось, а появилась возможность брать собранные под нее бинарные пакеты из той самой новой версии без пересборки.

а high precision POSIX таймеры как не работали, так и не работают... Linux'овый libc и kernel - отстойнейшая поделка и наглядный пример того, как недоучи пишут софт :(

--седайко стюмчик

и что там неработает c таймерами ? setitimer/getitimer ?

> а high precision POSIX таймеры как не работали, так и не работают... Linux'овый libc и kernel - отстойнейшая поделка и наглядный пример того, как недоучи пишут софт :(

> --седайко стюмчик

О, жабобыдлокодеры уже стали притворяться кернел хакерами. :)

SKYRiDER **, попиши с моё а потом тявкай

--седайко стюмчик

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

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

Ему нужен патч fix_hands_routing.diff

--- sedajko_stjumchik.orig 2006-08-24 23:32:00.000000000 +0400 +++ sedajko_stjumchik.fixed 2006-08-24 23:33:16.000000000 +0400 @@ -1,2 +1,2 @@

- #define HANDS_CONNECTOR "/dev/ass" + #define HANDS_CONNECTOR "/dev/shoulders"

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

Ему нужен патч fix_hands_routing.diff

--- sedajko_stjumchik.orig 2006-08-24 23:32:00.000000000 +0400
+++ sedajko_stjumchik.fixed 2006-08-24 23:33:16.000000000 +0400
@@ -1,2 +1,2 @@

- #define HANDS_CONNECTOR "/dev/ass"
+ #define HANDS_CONNECTOR "/dev/shoulders"

uman (*), обсуждать здесь технические вопросы - метать бисер перед свиньями. посмотрите на комментарии, какие ублюдки здесь флэймят. что самое неприятное подобный тон наблюдается исключитально в русскоязычных форумах

--седайко стюмчик

фигня, вы ещё виндовсь не видели

bugmaker ***, видели видели :) и там (в Windows) всё это работает на радость хорошо (и _быстро_ )

--седайко стюмчик