Начат проект создания новой реализации libc

http://www.unix.org/version3/online.html

Здесь.

>posix в реализации под линукс (pthread и т.д.)

??? Posix один. А тараканы реализаций изучать не нужно.

http://bits.blogs.nytimes.com/2009/06/15/sun-is-said-to-cancel-big-chip-project/
Про rock - правда. Ларри - редиско :(

Да в минорных, иначе почему при каждом релизе дров заявляется поддержка новых минорных версий ядра.

> http://www.channelregister.co.uk/2009/06/15/sun_kills_rock_sparc/

Краткий перевод: "2 человека, которые не представились, говорят, что Сан свернёт работу над чипом, который «почти готов» с прошлой осени. Потому, что их удовлетворяют существующие чипы Fujitsu. Официально Сан слухи не комментирует." Может оказаться неправдой, может — не свёртыванием, а заморозкой, но звучит правдоподобно.

> Месяц или 2 назад я читал о том, что Фуджитсу отказалась развиавть процессора Спарк.

А месяц назад представила прототип очередного чипа SPARC64 VIIIfx "Venus": http://www.theinquirer.net/inquirer/news/1137342/fujitsu-unveils-world-s-fast... http://lenta.ru/news/2009/05/15/fujitsu/

> Отсутствие поддержки чего-либо, что выходит за рамки POSIX 2008

Кто-нибудь может дать ссылку на краткий список расширений GNU, не входящих в POSIX 2008? К чему относится, например, iconv?

> http://www.unix.org/version3/online.html

Register to Read the Specification

Под каким названием искать в торрентах?

>>> Оракл остановил разработку сановского Рока

>>Ссылку!!111

>http://www.channelregister.co.uk/2009/06/15/sun_kills_rock_sparc/

Ну там хоть не говорят о том, что Fujitsu забила на SPARC: "If Rock is dead, it's a safe guess that Oracle will continue to partner with Fujitsu for midrange and high-end Sparc64 servers "

И вроде Niagara еще жива: "it will probably try to position the future "Niagara-III" 16-core Sparc T series chips - if they survive the knife - as the future for Sparc computing".

А e-mail someone@linux.org.ru, имя/фамилиё Вассисуарий Пупкин + страну Афганистан вбить - не? :)

>Ну там хоть не говорят о том, что Fujitsu забила на SPARC:
Да.
Так я же и написал: "кажется" так как не был уверен в источнике.

> Вот бы еще компиллер кроссплатформенный , написанный с нуля.

Clang. правда C++ ещё не запилили в нём.

>, так это фразы про то, что развитие libc безнадёжно зашло в тупик и загнило.

Чудак не относится к авторам либс. К тому же у нее неподходящая лицензия.

>Я способностей к телепатии не проявлял никогда, не говоря уже об улавливании мыслей четвертьвековой давности.

In 1980, Stallman and some other hackers at the AI Lab were refused access to the source code for the software of the first laser printer, the Xerox 9700. Stallman had modified the software on an older printer (the XGP, Xerographic Printer), so it electronically messaged a user when the person's job was printed, and would message all logged-in users when a printer was jammed. Not being able to add this feature to the Dover printer was a major inconvenience, as the printer was on a different floor from most of the users. This one experience convinced Stallman of people's need to be free to modify the software they use

Как я в роли телепата?

>:спользовать уже существущее ПО

Существующее _free software_. Не думай что я не заметил. Такая мелкая подмена понятий - столман придумал FOSS как идеологию - что явный велосипед.

>Если программа тебя не устраивает - пиши патчи. Если патчи не берут в апстрим - можно форкнуть, на худой конец. Это же free software.

Это что мантра? Линус - че ты взялся за этот велосипед с квадратыми колесами который стал линуксом? Писал бы патчи в миникс - старика Танненбаума порадовал.

> Писал бы патчи в миникс - старика Танненбаума порадовал.

Ну ты-то должен знать, что Танненбаум не принимал патчей, и не хотел, чтобы Minix использовали в реальном деле.

> int a(){ foo; } void * b(){ return &a; } 
> адрес а отличается от "где мы" всегда на константу. 

с чего бы это? особенно, если в библиотеке.

на этапе компиляции совсем не ясно, куда нас
"a" приведет. и дело вовсе не в weak symbols.

вот если оно static, тогда можно оптимизировать.

у gcc есть еще какая-то возможность сказать, что
"a" должно быть "тут же", но я забыл.

> компиляцию в raw бинарь

а это что такое?

> - там просто неверный код генерится

хм. а что там не так?

> уж выкинули бы этого уродца и сделали с нуля. 

сначала бы сделать, потом уж думать про выкинуть, не?

одна из этих 2х задач не вполне тривиальна.

> Уже было, man itanium, вот только амдэшники запилили его своей идиотской x86_64.

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

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

Нет, это вы приходите к этому выводу. :)

>Ну ты-то должен знать, что Танненбаум не принимал патчей, и не хотел, чтобы Minix использовали в реальном деле.

Ну так я про то и говорю - надо было добиваться, перевестись из Хельсинки в Амстердам (трава опять же) - сели бы со стариком, обговорили за косячком на тему принятия патчей в миникс - не было бы известного диалога:)

Но не дай бог изобретать велосипед пока все пороги не обиты и форки не попробованы:)

Видимо написать библиотеку libc с нуля - это единственный возможный способ сделать наконец поддержку POSIX в Linux хотя бы в libc.
Если эта библиотека будет еще и портабельной - вообще будет очень хорошо.

Насчет поддержки расширений.
Видимо чтобы хоть как-то ограничить себе объем работ предполагается что будет POSIX и все расширения используемые в Linux идут лесом.

То что какие-то программы перестанут собираться на этой библиотеке. Ну к тому моменту когда библиотека станет стабильной эти программы либо умрут, либо будут переписаны без этих расширений. Написание и отладка такой библиотеки - это не один год.

Использование лицензии BSD для библиотеки.
Я думаю это хитрый ход. Во-первых, в этом случае коммерсанты смогут использовать эту библиотеку без всяких ограничений - в отличие от libc/glibc в Linux - где их ограничивает GNU License.
Во-вторых никто не мешает комерсантам вложить немного денег в разработку этой библиотеки - эти деньги вернутся к ним же.
То есть использование лицензии BSD даст для библиотеки большую популярность и распространенность.

>Для 64-х бит это малоактуально, слава всем. %rip никто не отменял же?
для 64-х бит rip - это очередное изнасилование трупа.

у вас ~70тб адресного пространства. почему бы просто не выделять статически каждой либлиотеке её законное место начиная с какого нибудь терабайта? rip автоматически становится не нужен, динамический линковщик опускается до уровня двух вызовов open+mmap.

> кроме линакса. В линаксе
Ссаныч -к логопеду сходить не пробовал.
Повторяй: "лиии-нукс"

> поддержку POSIX в Linux хотя бы в libc.
> лицензии BSD для библиотеки.
rotfl. много вложено в fbsd? запомните, bsdl хорошо работает только в 2 случаях - абсолютный JFF и наличие хорошего спонсора, которому покласть на ROI.
вообще - по теме - это УГ и очередной сферический конь в вакууме
http://lurkmore.ru/%D0%A1%D1%84%D0%B5%D1%80%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%...
закапывайте!

>с чего бы это? особенно, если в библиотеке.
а с того что они в одной секции .text лежат.

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

пусть секция другая, но у вас в образе сразу после кода лежит таблица адресов интересных нам секций. её заполнит линкер - и это довольно быстро. тогда механизм похож на текущий - но таблица адресов секций на порядки меньше. и кэшу приятно и линкер летает.
адрес такой "удалённой" функции можно даже не искать, а просто в начале секции сделать аналог .plt - затычки длинной 8 байт

>а это что такое?
плоский бинарь без заголовков

>хм. а что там не так?
пусть А() лежит по адресу 0хf010 от начала файла. начало файла в памяти в регистре ebx и компилер про это знает. но вместо адреса
lea reg, [ebx+0xf010]
он положит в регистр первые 4 байта функции
mov reg, [ebx+0xf010]

проблема в том, что гцц по сути не кроссплатформенный. он жестко заточен под формат elf.

>>> Epic_fail
> Долго объяснять, если ты не знаешь, что такое EPIC :)
неужели итаник? как известно, он - EPIC CPU (Explicitly Parallel Instruction Computing)
и, как изветсно, у него провал. т.е. epic fail.;-)

Скажыте, а заявлена ли совместимость снизу вверх в пределах libposix?

Или будем опять как и с libc кактус жевать?

> Видимо написать библиотеку libc с нуля - это единственный возможный способ сделать наконец поддержку POSIX в Linux хотя бы в libc.

Бгг. NPTL, значит, не катит как улучшение поддержки POSIX. Каких именно возможностей POSIX тебе не хватает?

> Использование лицензии BSD для библиотеки. Я думаю это хитрый ход.

Ага, для того, чтобы иметь возможность ныть "злые линуксоиды не используют наш классный велосипед".

> Я думаю это хитрый ход. Во-первых, в этом случае коммерсанты смогут использовать эту библиотеку без всяких ограничений - в отличие от libc/glibc в Linux - где их ограничивает GNU License.

Да, LGPL их пипец как ограничивает. BSDL лишь даст возможность создавать закрытые, несовместимые форки...

> интелу взять и разработать новую архитектуру с нуля . Забить на все
> устаревшие костыли
дык они так и сделали - нвоый костыль, Итаник называется. EPIC architecture (fail?).

> затычки длинной 8 байт
для начала Вам надо научиться по-русски выражаться - длина пишется с одной "н". stub - не затычка.

>линкер генерирует примитивный код только в .plt, типа положи то-пойди туда, а в жизни занимается релокацией.

Ну я так понимаю, что линкер - единственный, кому известны действительные смещения символов в результирующем бинарном файле. Иначе говоря, чтобы lea eax,[ebx+relative_address] заработало, линкер должен подставить вместо relative address (offset symbol - offset current_function + const), где const - это размер пролога функции. Или я неправильно понимаю?

именно. бага в том, что по какой дикой традиции в elf релокаются все функции по отдельности, а сам формат инфы о релоках жуток и страшен аки чорт. могли бы для классов vtable отдельно размещать и релоки давать относительно плавающего начала секции. это бы стартовало мгновенно в случае ++снутого кода. weak символы и переопределение не такая уж частая цацка, чтоб ради них тормозили все программы.

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

Вот! Наконец-то! Речь не мальчика, но мужа!

>BSDL лишь даст возможность создавать закрытые, несовместимые форки...

И что? Кто-то от этого сон потерять должен?

> > с чего бы это? особенно, если в библиотеке.
> а с того что они в одной секции .text лежат.

мда.

$ cat lib.c
#include <stdio.h>

void a(void) { printf("gcc is stupid\n"); }

void b(void) { a(); }

$ cat main.c
#include <stdio.h>

void a(void) { printf("ckotinko is not that smart\n"); }

extern void b(void);

int main(void) { b(); return 0; }

$ cc -Wall -fpic -shared -o libtst.so lib.c 
$ cc -Wall -L. -ltst -o tst main.c && LD_LIBRARY_PATH=. ./tst
ckotinko is not that smart
 
> плоский бинарь без заголовков

хз, не сталкивался.

> Напоминает переписывание бздшниками GNU coreutils, да так что бы ls другими цветами по умолчанию раскрашивал.
Олень, ты хоть знаешь, с какого года в БСД есть ls? пойми, не весь мир вокруг линукса вращается, никому нафиг не надо кореутилс переписывать, есть же свои, кошерные.

> это можно и конфигом емнип. лучше бы они gcc свой написали. конкуренция была бы. а то пока только одни потуги да пуки
есть, pcc называется. да, пока не готов. а ты помог?

>weak символы и переопределение не такая уж частая цацка, чтоб ради них тормозили все программы.

Если что, то без weak символов не работали бы валгринды, socksify и все, что использует LD_PRELOAD.

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

>ЗЫ : Вот бы еще компиллер кроссплатформенный , написанный с нуля. Тогда уж точно все перестанут дрочить на gcc =)

У тебя на gcc не встает чтоли? Или ты из клана бздунов, которые оргазмируют от всего, что "как GNU, но не GNU"?

> Олень, ты хоть знаешь, с какого года в БСД есть ls? пойми, не весь мир вокруг линукса вращается,

Уважаемый, вы в курсе, что такое GNU environment, в каком году оно начало формироваться и какое цели преследовались при его создании? Хинт: никаким линуксом тогда не пахло и в проекте.

Теперь количество дистров вырастет в 2 раза? Или каждый дист будет не на 3 а на 6 DVD поставляться? Проги собранные под старый libc, + проги собранные под brand new libc?

> Уважаемый, вы в курсе, что такое GNU environment, в каком году оно начало формироваться и какое цели преследовались при его создании?
что за менторский тон, конечно в курсе. и что, в бсд тогда не было ls?

> и что, в бсд тогда не было ls?

В каком "бсд"? И какое отношение имеет тот "бсд" (который "тогда") к сегодняшним?

А про то, что в сегодняшнем Solaris'е больше от "того бсд", чем в сегодняшних Free/Net/Open/etc. BSD - ЛОР-овские бсдишники в курсе?

ты это, думай, что пишешь. В Солярисе значительно меньше от BSD 4.4 Lite , чем в OpenBSD и NetBSD. про FreeBSD не скажу. причем, как в плане технологий и тактики решений, так и реализации.

все современные бсд - прямые потомки bsd 4.4 lite, потомки не только идеологические, но и с полным заимствованием кода. все они содержат libc и "coreutils" в значительной степени основанный на bsd 4.4, и, соответственно, на его более ранних версиях. именно об этой реализации, которой уже больше тридцати лет, и идет речь.

// меня достало хамство вполне приличных с виду людей. вы как только слышите "bsd", так сразу начинаете кидаться говном. я был о вас лучшего мнения.