Разрабатываемый в рамках проекта LLVM компилятор Clang (http://clang.llvm.org/) поднялся на новую ступень развития, связанную с улучшением поддержки кода на языке C++, - при помощи Clang удалось пересобрать (http://blog.llvm.org/2010/05/clang-builds-boost.htm) всю коллекцию свободных С++-библиотек Boost (http://www.boost.org/). Boost расширяет список определенных в стандарте библиотек, являясь предтечей для включения новых библиотек в стандарт. В Boost активно используются такие передовые технологий языка С++, как шаблоны и метапрограммирование. Поддержка Boost, являясь камнем преткновения для многих компиляторов, демонстрирует полноту поддержки стандарта языка C++.
Clang полностью преодолел регрессивную проверку на совместимость c Boost, пройдя все связанные с C++ тесты. В настоящий момент, судя по представленному на сайте Boost отчету (http://www.boost.org/development/tests/release/developer/sum...), при тестирова...URL: http://blog.llvm.org/2010/05/clang-builds-boost.html
Новость: http://www.opennet.me/opennews/art.shtml?num=26705
кто там еще сомневался в необходимости llvm/clang? Остался последний оплот gcc - Qt, но и там всего лишь одна ошибка не дающая скомпилировать библиотеку.
>кто там еще сомневался в необходимости llvm/clang? Остался последний оплот gcc - Qt, но и там всего лишь одна ошибка не дающая скомпилировать библиотеку.А можно подробнее? То есть есть попытки собрать clang'ом Qt?
http://clang.llvm.org/cxx_status.html
Нет, не одна. Больше. Но работы над этим ведутся :)
> Остался последний оплот gcc - QtИ потом сразу наступит коммунизм? Ну уж фиг вам, коммунисты такими байками 70 лет кормили, так что когда наступит, тогда и ... :P.
Появится альтернатива, не более :Р
Угу. Если звезды зажигают - значит это кому-нибудь нужно. Остается только вопрос кому и нафига. Тут вон уже толстый тролль нечаянно спалил ответ кажись. Где все разработчики обитают - тем и нужно. А это жадная и стремная контора - Эппл. Прецеденты махрового жлобства от оной и их игр в откроем-закроем - были и есть. С их ядром хотя-бы.
да ладно, не смотря на то что я недавно наступил на грабли связанные с clang, что-то в портах из-за него не собиралось уже не помню что, я только за его развитие обеими руками и ногами. И вам луноходам от этого только один плюс, если так выйдет что clang хоть в чем-то будет лучше gcc то последнего тут же поправят и ускорят. Так что ты не переживай юзер, про тебя тоже не забыли :)
>> Остался последний оплот gcc - Qt
>
>И потом сразу наступит коммунизм? Ну уж фиг вам, коммунисты такими байками
>70 лет кормили, так что когда наступит, тогда и ... :P.
>Ты просто так ляпнул или глубоко в теме?
>кто там еще сомневался в необходимости llvm/clang?Ты ужо пересел на ClangBSD? Молодець, теперь _никгто не сомневается!!
а тем временем qt шники родят новую версию, где этих ошибок будет 10
Хм. Интересное конечно заявление. Сильное. Игрушки игрушками, но когда появляется возможность использовать продукт в реальных полезных проектах - это уже повод обратить на него внимание. Компилятор С++ без буста - это ноль без палки. А тут... Очень интересно. Пожелаем удачи ребятам и успехов! Зачет.
Да ладно Вам, говорите так как будто все что они до этого делали - были игрушки, а как удалось скомпилировать буст, сразу же стали серьезным проектом :)
Ну оно и сейчас как бы игрушка. Пока что. По крайней мере на фоне матерых по самое нехочу GCC или MSVC. Но - прогресс налицо, а это уже серьезная заявка. Глядишь, такими темпами скоро ребята и перестанут восприниматься как игрушка.
MSVC-то матерый? Перечитайте новость. А llvm уже давно не игрушка. Сырой, да.
Можно увидеть список проектов, которые используют его в полный рост в продакшене?
>Можно увидеть список проектов, которые используют его в полный рост в продакшене?Спросите в Apple.
Игрушка, игрушка. Когда догонит GCC по количеству платформ - тогда можно будет сравнивать.
Тоже мне, аргумент. Убрать из GCC поддержку i386/x86_64 и все, проект автоматически станет совершенно бесполезен для подавляющего количества своих пользователей -> радостно загнется тихой сапой. И никакие гирлянды самых разнообразных и вычурных архитектур ему не помогут. Разве что ARM останется, но и на неё он далеко не уедет.
Уедет на ARM и MIPS. Нормальных свободных компиляторов под эти архитектуры просто больше нет.
> Разве что ARM останется, но и на неё он далеко не уедет.Ну вы просто не заметили сколько девайсов на ARM, MIPS, AVR, MSP430, ... юзает этот компилер. От мелких таракашек до довольно увесистых систем. Лет через стопицот может быть clang и llvm чего-то такого и достигнут. Но поскольку эпплу это не сильно то и надо (кроме может быть топовых ARM в их ифонах) - достигаться наверное будет весьма долго, черт возьми. А потом еще и спасибо если эппл не начнет свои игры в откроем-закроем, как с дарвинским ядром. В итоге ссут кипятком по моим наблюдениям разе что бздуны, которым "i386 only" - не проблема (все-равно у них толком на других платформах ничерта не работает). Зато лицензия кошерная - позволяет япплу и т.п. в закрывашки поиграть. А GCC извините более-менее прилично генерит код под кучу архитектур и окружений. Не через сто лет а сейчас. И никакой эппл его не закроет в случае чего. Так что лично я от него отказываться как-то не собираюсь. И каких-то ограничений от лицензии компилера не испытываю. Вот ведь досада для тех кто тут в пользу проприетарщиков троллит, а? :)
Ну от чего же, их я не забыл. Но количество разработчиков, которые работают с указанными платформами несоизмеримо меньше, нежели с обычным писюковым десктопом. Думаю, не сильно ошибусь, если скажу что на порядки. Да и самих девайсов далеко не так много, как это может показаться на первый взгляд. На фоне тех же писюков. И не все скажем армовские девайсы работают под Linux. Как прямое следствие не все они так уж нуждаются в GCC. Конечно, это не PDP-11 сегодня. Но тем не менее, до рынка обычный кандовых писюков по распространённости и трудоемкости ой как далеко. Со всеми вытекающими для инструментария, который гипотетически был бы заточен именно под ARM, MIPS а уж тем более под AVR.
большинству разработчиков под писюки, gcc нахрен не нужен. Им нужен .net, java, VB6, Delphi и в нагрузку MSVC. GCC нужен только маргиналам, которые вместо того, чтобы писать бизнес-приложения, страдают какой-то хренью под названием "опенсорц"
>большинству разработчиков под писюки, gcc нахрен не нужен. Им нужен .net, java,
>VB6, Delphi и в нагрузку MSVC. GCC нужен только маргиналам, которые
>вместо того, чтобы писать бизнес-приложения, страдают какой-то хренью под названием "опенсорц"
>Если бы не усилия этих маргиналов, не было бы в т.ч. и этого сайта. И тролили бы вы соотв. не здесь но на каком-нибудь дваче, упячке, кроветке.ру или как там их называют.
>Если бы не усилия этих маргиналов, не было бы в т.ч. и
>этого сайта. И тролили бы вы соотв. не здесь но на
>каком-нибудь дваче, упячке, кроветке.ру или как там их называют.Согласен. Слава Столлману!
Но основной посыл моего поста не изменился, в большинстве случаев разработчикам под писюки gcc нахрен не нужен.
Если из gcc нахрен выкинут поддержку x86 и x86_64, его все равно будут развивать те, кому нужен компилятор для туевой хучи архитектур, тем более, что для x86 компиляторов жопой жуй.
А вот если сделать наоборот, т.е. выкинуть всё кроме x86 и x86_64, то ИМХО gcc загнётся.
>>Если бы не усилия этих маргиналов, не было бы в т.ч. и
>>этого сайта. И тролили бы вы соотв. не здесь но на
>>каком-нибудь дваче, упячке, кроветке.ру или как там их называют.
>
>Согласен. Слава Столлману!Он то здесь причём? Не стоит совсем уж всех собак то на старика вешать.
>Но основной посыл моего поста не изменился, в большинстве случаев разработчикам под
>писюки gcc нахрен не нужен.Ну если быть откровенным, то в большинстве случаев разработчикам под писюки и Linux то не нужен. В подавляющем большинстве случаев. Со всеми вытекающими типа нужности GCC. Но x86_64 - это не только и не столько десктопы, сколько серверные приложения. А вот тут уже не замечать значимость Linux & K просто невозможно.
>Если из gcc нахрен выкинут поддержку x86 и x86_64, его все равно
>будут развивать те, кому нужен компилятор для туевой хучи архитектур, тем
>более, что для x86 компиляторов жопой жуй.Будут. Вопрос лишь в эффективности и скорости этого развития. А так, теоретически конечно будут, да. Где-то на уровне OpenWatcom. Может, чуть поживее. Но не сильно.
>А вот если сделать наоборот, т.е. выкинуть всё кроме x86 и x86_64,
>то ИМХО gcc загнётся.Боюсь, основная масса даже и не заметит, что из GCC что-то выкинули. И спокойно продолжит использовать его далее.
>>Согласен. Слава Столлману!
>
>Он то здесь причём? Не стоит совсем уж всех собак то на
>старика вешать.Это такой толстый-толстый троллинг.
>
>>Но основной посыл моего поста не изменился, в большинстве случаев разработчикам под
>>писюки gcc нахрен не нужен.
>
>Ну если быть откровенным, то в большинстве случаев разработчикам под писюки и
>Linux то не нужен. В подавляющем большинстве случаев. Со всеми вытекающими
>типа нужности GCC.Согласен.
>Но x86_64 - это не только и не
>столько десктопы, сколько серверные приложения. А вот тут уже не замечать
>значимость Linux & K просто невозможно.x86_64 без gcc один хрен не загнётся.
>
>>Если из gcc нахрен выкинут поддержку x86 и x86_64, его все равно
>>будут развивать те, кому нужен компилятор для туевой хучи архитектур, тем
>>более, что для x86 компиляторов жопой жуй.
>
>Будут. Вопрос лишь в эффективности и скорости этого развития. А так, теоретически
>конечно будут, да. Где-то на уровне OpenWatcom. Может, чуть поживее. Но
>не сильно.
>Будут весьма живо, потому что вариантов больше негусто. Тем более, что для eval board сейчас стандарт - делать gcc toolchain которым можно сразу что-то делать.
остальные монстры типа keil и иже с ними, это уже для тех, кто делает серьезное железо за серьезные бабки, а большинству отлично хватает gcc.
>>А вот если сделать наоборот, т.е. выкинуть всё кроме x86 и x86_64,
>>то ИМХО gcc загнётся.
>
>Боюсь, основная масса даже и не заметит, что из GCC что-то выкинули.
>И спокойно продолжит использовать его далее.В том-то и дело, что заметят. в embedded немалая часть зависит от gcc
> Будут весьма живо, потому что вариантов больше негусто. Тем более, что для eval board сейчас стандарт - делать gcc toolchain которым можно сразу что-то делать.
> остальные монстры типа keil и иже с ними, это уже для тех, кто делает серьезное железо за серьезные бабки, а большинству отлично хватает gcc.Дальше остается лишь вопрос а хватит ли сил времени и знаний у тех, кто не делает 'серьезное железо за серьезные бабки' поддерживать на плаву такого монстра, как GCC? Ибо в кишках он действительно не сахар и по своей воле ковыряться в этой какашке в трезвом уме и здравой памяти полезет только сумасшедший..
>Дальше остается лишь вопрос а хватит ли сил времени и знаний у
>тех, кто не делает 'серьезное железо за серьезные бабки' поддерживать на
>плаву такого монстра, как GCC? Ибо в кишках он действительно не
>сахар и по своей воле ковыряться в этой какашке в трезвом
>уме и здравой памяти полезет только сумасшедший..Скорее всего этим займется(занимается, я хз) Atmel, NXP и остальные. Тому же Atmel gcc очень полезен, ибо для ихнего AVR32(он же MIPS) с компиляторами насколько я понимаю(в живую эти процы не использовал) не очень весело.
Я думаю, сейчас поддержку таких архитектур пилят люди, которым железячные компании платят деньги.
От ты юзер опять начинаешь а. Знаешь же прекрасно что сейчас фряшники делают упор на развитие платформы ARM, и в скором времени все будет как надо. Хорош уже, знаем что твой линукс белый и пушЫстый, а все остальное "тихо посасывает". :) Интересно когда ты устанешь расхваливать линукс как все равно что бил гейц венду а? :)
..в скором времени.. ..станет..
Это наверное ключевые слова. Вот как станет - welcome :)
Пока фряшники сделают нормальный порт на ту туеву хучу ARM SoC систем, они охренеют раньше.Ну или как минимум на все основные devboard, чтобы можно было хоть как-то с чего-то пытаться использовать фряху в embedded, пройдет еще года 1.5-2-... А железяки нужны сейчас.
>От ты юзер опять начинаешь а. Знаешь же прекрасно что сейчас фряшники
>делают упор на развитие платформы ARM, и в скором времени все будет как надо.Ну вот когда будет, тогда и приходите. А пока почему-то работоспособные порты есть только у MS+Danger, Apple, Juniper и панасоника. От коих лично мне ни холодно, ни жарко как-то - они где-то там, у них, а не у меня. Т.к. поделиться они как обычно забыли. Ну а потому из относительно работоспособных портов только нечто для каких-то древних ископаемых железок которые в продаже хрен найдешь, не говоря о том что за это время вышло полно железок параметры которых лучше в РАЗЫ (что и стало поводом для пропадания ископаемых из продажи).
>[оверквотинг удален]
>не начнет свои игры в откроем-закроем, как с дарвинским ядром. В
>итоге ссут кипятком по моим наблюдениям разе что бздуны, которым "i386
>only" - не проблема (все-равно у них толком на других платформах
>ничерта не работает). Зато лицензия кошерная - позволяет япплу и т.п.
>в закрывашки поиграть. А GCC извините более-менее прилично генерит код под
>кучу архитектур и окружений. Не через сто лет а сейчас. И
>никакой эппл его не закроет в случае чего. Так что лично
>я от него отказываться как-то не собираюсь. И каких-то ограничений от
>лицензии компилера не испытываю. Вот ведь досада для тех кто тут
>в пользу проприетарщиков троллит, а? :)Тролль здесь в первую очередь вы.
1. GCC относительно прилично генерит код только под те архитектуры, где он активно используется. Объяснить, почему, или сами догадаетесь?
2. Apple может поступать как ей заблагорассудится, сейчас они развивают LLVM, и это хорошо. Если закроют — будет плохо, но проект вряд ли умрёт — ИМХО, он уже перешёл необходимую границу популярности.
3. Наезды на *BSD про портабельность смешны. Покажите мне _дистр_ (а не голое ядро с недопиленным под эту платформу тулчейном) Linux, портированный на большее число платформ, чем NetBSD или OpenBSD, и при этом более популярный. А? Или вы одним ядром живы, без софта?
>3. Наезды на *BSD про портабельность смешны. Покажите мне _дистр_ (а не
>голое ядро с недопиленным под эту платформу тулчейном) Linux, портированный на
>большее число платформ, чем NetBSD или OpenBSD, и при этом более
>популярный. А? Или вы одним ядром живы, без софта?С каких это пор, принято мерятся портируемостью дистрибутивов?
Linux - это ядро, а вся ос - это ядро + обвяз из гнутых утилит. ПРи этом очень многие производители вместо того, чтобы брать готовый велосипед, делают свой с квадратными колесами, но который удобен в данном конкретном случае.
>
>>3. Наезды на *BSD про портабельность смешны. Покажите мне _дистр_ (а не
>>голое ядро с недопиленным под эту платформу тулчейном) Linux, портированный на
>>большее число платформ, чем NetBSD или OpenBSD, и при этом более
>>популярный. А? Или вы одним ядром живы, без софта?
>
>С каких это пор, принято мерятся портируемостью дистрибутивов?Спросите у User294.
>Linux - это ядро, а вся ос - это ядро + обвяз
>из гнутых утилит. ПРи этом очень многие производители вместо того, чтобы
>брать готовый велосипед, делают свой с квадратными колесами, но который удобен
>в данном конкретном случае.Отлично, раз с ваших слов сделать нормальный дистр Linux под любую платформу, где есть Linux-ядро (и, соответственно, компиляторный тулчейн марки GNU), легко и просто, продемонстрируйте.
>Отлично, раз с ваших слов сделать нормальный дистр Linux под любую платформу,
>где есть Linux-ядро (и, соответственно, компиляторный тулчейн марки GNU), легко и
>просто, продемонстрируйте.не приписывай мне того, что я не говорил. Сделать нормальный образ для встраиваемой железяки - это адский геморрой, коим я сейчас занимаюсь. Точнее, дистрибутив для железяки уже есть, он работает, но там так сделано, что чем делать в нем серъезные изменения, проще взять buildroot, допилить его, добавить свои скрипты и пакеты и собрать образ подходящий под задачу.
Я говорил про то, что брать готовый дистрибутив для embedded - это во многих случаях нихрена не вариант.
>buildroot, допилить его, добавить свои скрипты и пакеты и собрать образ
>подходящий под задачу.
>
>Я говорил про то, что брать готовый дистрибутив для embedded - это
>во многих случаях нихрена не вариант.Так никто с этим (кроме, возможно, User294) и не спорит. :)
Повторюсь, был (не в первый раз, надо сказать) наезд, дескать, *BSD работают на считанных архитектурах. Автор наезда был ткнут носом в свою ложь (или, как это принято говорить в дипломатических кругах, некоторое преувеличение). Я никогда не говорил и даже не подразумевал, что портировать операционную систему — это легко!
Так что суть ваших претензий мне не совсем понятна; может, конечно, мне просто надо выспаться. :) А то у нас, фонатегов-бээсдэшникофф, зуд в рабочем месте не переводится (я про руки). ;)
>Повторюсь, был (не в первый раз, надо сказать) наезд, дескать, *BSD работают
>на считанных архитектурах. Автор наезда был ткнут носом в свою ложь
>(или, как это принято говорить в дипломатических кругах, некоторое преувеличение). Я
>никогда не говорил и даже не подразумевал, что портировать операционную систему
>— это легко!
>
>Так что суть ваших претензий мне не совсем понятна; может, конечно, мне
>просто надо выспаться. :) А то у нас, фонатегов-бээсдэшникофф, зуд в
>рабочем месте не переводится (я про руки). ;)*BSD работают на многих архитектурах, это да, но есть прокол, у армов, например, под каждый SoC ядро приходится подпиливать, из-за того, что у них одинаково только ядро, а набор периферии разный, различная распиновка и т.п., поэтому как минимум приходится доделывать инициализацию. Линукс использует много кто и много где, так что под все основные SoC в ядре есть код, его возможно надо немного поправить, чтобы он соответствовал реалиям платы, но это проблем никаких не вызывает. А как у *BSD с этим, я честно говоря не знаю.
Пример из жизни: есть плата на основе at91rm9200 - это SoC на основе arm920t. Порт NetBSD я не увидел, хотя старался, а линуксовое ядро там себя чувствует просто отлично с хрен знает какой версии(самое раннее, что я вживую видел - это 2.6.17)
>[оверквотинг удален]
>т.п., поэтому как минимум приходится доделывать инициализацию. Линукс использует много кто
>и много где, так что под все основные SoC в ядре
>есть код, его возможно надо немного поправить, чтобы он соответствовал реалиям
>платы, но это проблем никаких не вызывает. А как у *BSD
>с этим, я честно говоря не знаю.
>
>Пример из жизни: есть плата на основе at91rm9200 - это SoC на
>основе arm920t. Порт NetBSD я не увидел, хотя старался, а линуксовое
>ядро там себя чувствует просто отлично с хрен знает какой версии(самое
>раннее, что я вживую видел - это 2.6.17)Так о чём я и говорю: Linux — это ядро, а *BSD — это ОС. Сравнивать попросту некорректно. в *BSD не бывает так, что ядро работает, а остальная система — нет; поддержка всегда делается полноценная.
>Так о чём я и говорю: Linux — это ядро, а *BSD
>— это ОС. Сравнивать попросту некорректно. в *BSD не бывает так,
>что ядро работает, а остальная система — нет; поддержка всегда делается
>полноценная.тут как-то пофиг. Если будет работать ядро *bsd системы, то там будет работать и вся *bsd система. на армы бсдшный userland я так понимаю портирован. Тут вопрос именно в поддержке ядром конкретного SoC.
Ну и последний гвоздь в крышку этого гроба:
Товарищи БСДшники, запилите мне пожалуйста образ системы с ядром, чтобы он умел: ipfw, ipsec, openvpn, GRE-туннели, ppp,pptp,l2tp, ssh, httpd(без свистелок, только CGI), dyndns, nat, nat traversal - в 7 мегабайт с ядром, образ ФС сжат gzip, bzip2, ядро без сжатия. Сейчас такая штука с линуксом у меня есть и работает. Влезает конечно впритык, но влезает. Реально ли так поджать *BSD - лично для меня вопрос интересный.
Ок, нашел, фряху на данный SoC портировали, ладно.Но вопрос по образу в силе.
>>Так о чём я и говорю: Linux — это ядро, а *BSD
>>— это ОС. Сравнивать попросту некорректно. в *BSD не бывает так,
>>что ядро работает, а остальная система — нет; поддержка всегда делается
>>полноценная.
>
>тут как-то пофиг. Если будет работать ядро *bsd системы, то там будет
>работать и вся *bsd система.Именно. А Linux?
>на армы бсдшный userland я так понимаю портирован.
>Тут вопрос именно в поддержке ядром конкретного SoC.Хех, тут тогда вопрос конкретного интереса.
>Ну и последний гвоздь в крышку этого гроба:
>Товарищи БСДшники, запилите мне пожалуйста образ системы с ядром, чтобы он умел:
>ipfw,Обязательно ipfw или всё-таки любой подходящий фаервол?
> ipsec,
С этим проблем вообще нет.
>openvpn,
Именно openvpn?
>GRE-туннели, ppp, pptp, l2tp
То есть PPTP, L2TP и просто PPP, если быть корректным, так?
>ssh
ssh или sshd?
>httpd (без свистелок, только CGI)
Apache или просто Web-cервер с CGI?
>dyndns,
Клиент или сервер?
>nat, nat traversal
Опять-таки, проблем нет.
> - в 7 мегабайт с ядром, образ ФС
>сжат gzip, bzip2, ядро без сжатия.Эм, если не секрет, а почему ФС жать можно, а ядро низзя?
>Сейчас такая штука с линуксом
>у меня есть и работает. Влезает конечно впритык, но влезает. Реально
>ли так поджать *BSD - лично для меня вопрос интересный.Поджать-то можно, crunchgen ещё никто не отменял… Если не забуду и найдётся время, попробую сварганить на днях. Можете по email пнуть, если интересно.
>>>Так о чём я и говорю: Linux — это ядро, а *BSD
>>>— это ОС. Сравнивать попросту некорректно. в *BSD не бывает так,
>>>что ядро работает, а остальная система — нет; поддержка всегда делается
>>>полноценная.
>>
>>тут как-то пофиг. Если будет работать ядро *bsd системы, то там будет
>>работать и вся *bsd система.
>
>Именно. А Linux?Busybox c uClibc решают.
>[оверквотинг удален]
>>на армы бсдшный userland я так понимаю портирован.
>>Тут вопрос именно в поддержке ядром конкретного SoC.
>
>Хех, тут тогда вопрос конкретного интереса.
>
>>Ну и последний гвоздь в крышку этого гроба:
>>Товарищи БСДшники, запилите мне пожалуйста образ системы с ядром, чтобы он умел:
>>ipfw,
>
>Обязательно ipfw или всё-таки любой подходящий фаервол?ipfw я привел в пример, потому что про него я помню. А так, любой фаирволл
>
>> ipsec,
>
>С этим проблем вообще нет.
>
>>openvpn,
>
>Именно openvpn?openvpn обязателен.
>
>>GRE-туннели, ppp, pptp, l2tp
>
>То есть PPTP, L2TP и просто PPP, если быть корректным, так?Да. железяка должна уметь эти протоколы, как клиент.
Также требуется GRE в чистом виде.
>
>>ssh
>
>ssh или sshd?sshd(dropbear если он есть под BSD)
>
>>httpd (без свистелок, только CGI)
>что угодно, главное, чтобы маленькое и умело через cgi пускать шелловые скрипты
>
>>dyndns,
>
>Клиент или сервер?Клиент
>
>>nat, nat traversal
>
>Опять-таки, проблем нет.
>
>> - в 7 мегабайт с ядром, образ ФС
>>сжат gzip, bzip2, ядро без сжатия.
>
>Эм, если не секрет, а почему ФС жать можно, а ядро низзя?можно и ядро, но тогда грузится долго. Если получится ужать с ядром, тоже подходит.
>
>
>>Сейчас такая штука с линуксом
>>у меня есть и работает. Влезает конечно впритык, но влезает. Реально
>>ли так поджать *BSD - лично для меня вопрос интересный.
>
>Поджать-то можно, crunchgen ещё никто не отменял… Если не забуду и найдётся
>время, попробую сварганить на днях. Можете по email пнуть, если интересно.
>Хм, про crunchgen не слышал.
В качестве очень желательного дополнения, нужен gettext с выводом в utf-8. Консоль уметь utf-8 не обязана.
>>>GRE-туннели, ppp, pptp, l2tp
>>
>>То есть PPTP, L2TP и просто PPP, если быть корректным, так?
>
>Да. железяка должна уметь эти протоколы, как клиент.
>
>Также требуется GRE в чистом виде.Что значит «в чистом виде»? http://www.openbsd.org/cgi-bin/man.cgi?query=gre&apropos=0&s... ?
>>>ssh
>>
>>ssh или sshd?
>
>sshd(dropbear если он есть под BSD)http://matt.ucc.asn.au/dropbear/dropbear.html#platforms ;)
>>Поджать-то можно, crunchgen ещё никто не отменял… Если не забуду и найдётся
>>время, попробую сварганить на днях. Можете по email пнуть, если интересно.
>>
>
>Хм, про crunchgen не слышал.С помощью этого инструмента в *BSD (не скажу за все, правда) и делают установочные RAMDISK'и, например.
>В качестве очень желательного дополнения, нужен gettext с выводом в utf-8. Консоль
>уметь utf-8 не обязана.Эм-м-м, gettext — мягко говоря, тяжеловес. На OpenBSD/i386 у меня полный пакет (в Linux-дистрах его, AFAIK, иногда бьют на части) занимает три с половиной метра. Какой именно функционал от него нужен?
>>Также требуется GRE в чистом виде.
>
>Что значит «в чистом виде»? http://www.openbsd.org/cgi-bin/man.cgi?query=gre&apropos=0&s... ?Оно.
>>В качестве очень желательного дополнения, нужен gettext с выводом в utf-8. Консоль
>>уметь utf-8 не обязана.
>
>Эм-м-м, gettext — мягко говоря, тяжеловес. На OpenBSD/i386 у меня полный пакет
>(в Linux-дистрах его, AFAIK, иногда бьют на части) занимает три с
>половиной метра. Какой именно функционал от него нужен?нужны gettext и gettext.sh для локализации web-интерфейса. Не влезет и фиг бы с ним, не критично.
>Ну и последний гвоздь в крышку этого гроба:
>Товарищи БСДшники, запилите мне пожалуйста образ системы с ядром, чтобы он умел:
>ipfw, ipsec, openvpn, GRE-туннели, ppp,pptp,l2tp, ssh, httpd(без свистелок, только CGI), dyndns,
>nat, nat traversal - в 7 мегабайт с ядром, образ ФС
>сжат gzip, bzip2, ядро без сжатия. Сейчас такая штука с линуксом
>у меня есть и работает. Влезает конечно впритык, но влезает. Реально
>ли так поджать *BSD - лично для меня вопрос интересный.а зачем вам ядро без сжатия ?:) а то что вы описали - вполне себе впихивается в 4-6м у NetBSD - лично наблюдал такое :) порт NetBSD на edimax.
на FreeBSD делал на 32м флэшке такое (ключевое слово nanobsd/tinybsd + crunch)
казалось бы - может стоит руки править ?
>[оверквотинг удален]
>>сжат gzip, bzip2, ядро без сжатия. Сейчас такая штука с линуксом
>>у меня есть и работает. Влезает конечно впритык, но влезает. Реально
>>ли так поджать *BSD - лично для меня вопрос интересный.
>
>а зачем вам ядро без сжатия ?:) а то что вы описали
>- вполне себе впихивается в 4-6м у NetBSD - лично наблюдал
>такое :) порт NetBSD на edimax.
>на FreeBSD делал на 32м флэшке такое (ключевое слово nanobsd/tinybsd + crunch)
>
>казалось бы - может стоит руки править ?Ключевое слово AT91RM9200. Порта Net/Open BSD я на этот SoC так и не увидел.
Поделись ссылкой на edimax порт, интересно посмотреть, как они его сделали
>Повторюсь, был (не в первый раз, надо сказать) наезд, дескать, *BSD работают
>на считанных архитектурах.Кстати, а где используется BSD, на отличных от i386/amd64 архитектурах? (Это не троллинг, мне действительно интересно, да и сам я фанат FreeBSD)
>>Повторюсь, был (не в первый раз, надо сказать) наезд, дескать, *BSD работают
>>на считанных архитектурах.
>
>Кстати, а где используется BSD, на отличных от i386/amd64 архитектурах? (Это не
>троллинг, мне действительно интересно, да и сам я фанат FreeBSD)Из известного - Juniper использует нечто BSD-подобное в маршрутизаторах
>>на отличных от i386/amd64 архитектурах?
>Из известного - Juniper использует нечтоИ они, конечно не интел+ПК?? :-O Не верю.
>>>на отличных от i386/amd64 архитектурах?
>>Из известного - Juniper использует нечто
>
>И они, конечно не интел+ПК?? :-O Не верю.Они MIPS
Молодцы, у них [лишних] денег на FreeBSD больше, чем у Эппла.
>Молодцы, у них [лишних] денег на FreeBSD больше, чем у Эппла.JUNOS - это не FreeBSD, это что-то BSD подобное, подробнее сказать сложно, ибо закрыто.
Не ужели не доверяете тому, что они сами говорят?"JUNOS software is, indeed, based on FreeBSD. Probably the most obvious benefit of using FreeBSD in our software is the Unix-like environment that comes with it."
Никаких BSD-like, именно FreeBSD.
>Не ужели не доверяете тому, что они сами говорят?
>"JUNOS software is, indeed, based on FreeBSD. Probably the most obvious benefit
>Никаких BSD-like, именно FreeBSD.Доверяю! Написано "based on FreeBSD", значит не "именно" и даже не "-like".
>Тролль здесь в первую очередь вы.В первую ли? Тут вон еще толстые какие-то шляются. Даже не скрывают что толстые, при том если обратить внимание на их вектора троллинга - можно интересные выводы сделать :)
>1. GCC относительно прилично генерит код только под те архитектуры, где он
>активно используется.Что логично, черт возьми - если архитектура ну совсем никем не используется - всем как бы пофиг на качество кода для нее.
>Объяснить, почему, или сами догадаетесь?
Наверное вам хочется примерять погоны Капитана Очевидность ;)
>2. Apple может поступать как ей заблагорассудится,
Угу. Как оракл с опенсолярщиками. Захотим - прокатим. Не захотим - не прокатим.
>ИМХО, он уже перешёл необходимую границу популярности.
А Толстый трололо утверждал недавно что из сторонних разработчиков аж целый один человек. Думается похоже на ситуацию с опенсолярой...
>Или вы одним ядром живы, без софта?
Да вот знаете, в какомнить openwrt или n900 софт чуть другой чем на десктопе. Похожий, но облегченный. И вы знаете, это не баг, это ФИЧА. Экономия ресурсов, типа. А какойнить опенбсд или нетбсд на таких девайсах вообще толком не заработает, для начала. Как максимум фрибздю кой-как вон пытались тут портировать на мипсовые железки. Вышло имхо довольно уныло т.к. бздя под такое применение не заточена чуть более чем полностью, но по крайней мере - оно судя по логам загрузкт подавало признаки жизни а даже могло делать что-то осмысленное. Хотя выбирать между IPSec маршрутизатором, точкой доступа и чем там еще путем переливки фирмвари, извините, называется "рослый полярный лис", имхо.
>>Или вы одним ядром живы, без софта?
>
>А какойнить опенбсд или нетбсд на
>таких девайсах вообще толком не заработает, для начала. Как максимум фрибздю
>кой-как вон пытались тут портировать на мипсовые железки. Вышло имхо довольно
>уныло т.к. бздя под такое применение не заточена чуть более чем
>полностью, но по крайней мере - оно судя по логам загрузкт
>подавало признаки жизни а даже могло делать что-то осмысленное.http://www.netbsd.org/ports/#ports-by-cpu
http://www.openbsd.org/plat.htmlЕщё вопросы для гугля?
> Хотя выбирать между IPSec маршрутизатором, точкой доступа и чем там еще путем переливки
>фирмвари, извините, называется "рослый полярный лис", имхо.Не понял?
> http://www.netbsd.org/ports/#ports-by-cpu
> http://www.openbsd.org/plat.html
> Ещё вопросы для гугля?Ports-by-CPU применительно к NetBSD - это все равно что сферический конь в абсолютном вакууме. Интересуют не наличие галочек 'отстрелялся' но конкретные рабочие поддерживаемые BSP (Board Support Package). Чтобы на заданной железке работала вся доступная периферия. И хитрожопые доморощенные итнерфейсы на LCD и кнопочки выведенные через &^%&^% GPIO и ещё бог знает какие исхищрения китайской технической мысли.
Давайте попробуем угадать, если мы возьмем среднестатистического как температура по больнице вендора желтожелеза 'для домашнего эбдедед', как распределятся галочки 'Supported By' для Win*, Linux и *BSD? И сколько из этих вендоров вообще знает слово NetBSD?
Hint: Ни одного. Вообще. В лучшем случае - Linux.
PS: Да, я в своё время натрахался с такими железками. И в том числе под NetBSD. И смотрю на всю эту гирлянду 'поддерживаемых CPU' чрезвычайно скептически. Без конкретики применительно к заданному железу эти галочки просто ни о чём. Совершенно.
Дурак или прикидываешься? На кой хрен Эпплу закрывать llvm? Чтобы продавать его? За деньги никто компилятор не купит, раз есть уже GCC. Или ты не понимаешь почему лицензия BSD? Чтобы они могли без проблем использовать код в своих тулзах типа XCode и так далее. Закрывать компилятор им просто невыгодно, так как это взаимовыгодный обмен между ними и сообществом. Хватит уже бредить.
> За деньги никто компилятор не купит, раз есть уже GCC.А вот компания Майкрософт считает иначе, продавая свою тулсень. Ну и Эппл ничем таким не лучше. Такие же проприетарщики, только еще более злючие. И закладываться на компилер который делает одна коммерческая компания с возможностью его закрыть - упаси боже, имхо. Чтобы потом как опенсолярщики обнаружить что компания решила показать фигу в силу тех или иных причин а форкать особо некому? Вы же сами сказали что все разработчики - из Эппл. А значит при создании этой штуки учтутся только интересы Эппл и рулить всем будет только он. Лично мне такое "счастье" ни к чему. В дерьмо я уже навляпывался, добавки не хочется.
> Чтобы они могли без проблем использовать код в своих тулзах типа XCode и так далее.
Флаг им в руки и барабан на шею. А мне эта их свобода нафиг не впилась и выглядит как-то стремно вообще: делает один единственный эппл который всегда может при приступе жабы приложить остальных фэйсом об тейбл и форкать особо как-то и некому. Вон опенсолярщики недавно уже тут радовались. Спасибо, конечно, но это вы сами плиз в такое вляпывайтесь.
> так как это взаимовыгодный обмен между ними и сообществом.
Так вы же сами сказали что никакакого сообщества по сути нет. Вы бы определились с показаниями, а то сами себе же и противоречите, мистер трололо ;)
> Хватит уже бредить.
Да, вот и я так считаю. Вы уж определитесь. А то путаетесь в показаниях. То взаимовыгодный обмен с комьюнити, блаблабла. А то никакого комьюнити как бы и нет. Как бы нестыковочка, yeah? Троллюго двухстандартное.
>> За деньги никто компилятор не купит, раз есть уже GCC.
>
>А вот компания Майкрософт считает иначе, продавая свою тулсень.Microsoft продают Visual Studio (среду разработки). Компилятор(-ы) доступен на халяву. Может, всё-таки стоит начать сначала изучать вопрос, а потом уже с апломбом что-то утверждать?
>>> За деньги никто компилятор не купит, раз есть уже GCC.
>>
>>А вот компания Майкрософт считает иначе, продавая свою тулсень.
>
>Microsoft продают Visual Studio (среду разработки). Компилятор(-ы) доступен на халяву. Может, всё-таки
>стоит начать сначала изучать вопрос, а потом уже с апломбом что-то
>утверждать?VS Express edition - уже бесплатная. Сторонние IDE умеющие MSVC уже есть.
>В итоге ссут кипятком по моим наблюдениям разе что бздуны, которым "i386
>only" - не проблема (все-равно у них толком на других платформах
>ничерта не работает).Эй, ты скакого бодуна это сказал?
i386, amd64, sparc64 — это основные платформы, на которых сопровождается исходный код и коллекция портов FreeBSD.
Остальные архитектуры (arm, mips, powerpc и др.) — эти да, поддерживаются отчасти и с портами не густо.
Рекомендую прочесть очень внимательно об аппаратной поддержке:
http://www.freebsd.org/releases/8.0R/hardware.html
"2.1 amd64
Since mid-2003 FreeBSD/amd64 has supported the AMD64 (“Hammer”) and Intel® EM64T architecture, and is now one of the Tier-1 platforms (fully supported architecture), which are expected to be Production Quality with respects to all aspects of the FreeBSD operating system, including installation and development environments."
прежде чем заявлять глупости. Да и об прогрессе LLVM/Clang в деле сборки FreeBSD на архитектурах i386 и amd64 тоже неплохо бы тебе держать "руку на пульсе":
http://wiki.freebsd.org/BuildingFreeBSDWithClang
а то такую ахинею временами несёшь, не убедившись в её наличии.
>Ну вы просто не заметили сколько девайсов на ARM, AVR...Ну да, ну да... Вот только в ARM он проигрывает Keil'у, а в AVR - IAR'у.
Однако в gcc 4.5 уже есть львиная доля С++0x фич, я уверен многие не устояли и начинают их использовать (auto, lambdas, ммм..). Надеюсь Clang++ догонит gcc 4.5 очень быстро.P.S. Кстати по некоторым тестам которые я проводил на моем raytracer'е, clang+llvm оптимизируют код слегка лучше по какой-то причине и дают стабильный прирост около 5-10% производительности. И это C++ код! Что меня удивило, clang++ и правда скомпилировал весь мой код без проблем. И мало того, что скомпилировал быстрее, так и скомпилировал лучше, серьезная заявка для нового С++ компилятора (или признак ущербности gcc, да простят меня верующие).
Будьте добры выложить код теста.
> я уверен многие не устояли и начинают их использовать (auto, lambdas, ммм..)Это не просто "ммм", а ням-ням, но вот я к сожалению не могу использовать, так как собирать весь софт приходится на Red Hat 4, где gcc версии 3.4, так как клиенты используют. Ни о каких C++0x и речи не может. В принципе конечно возможно собрать GCC 4.5 на этой машине и тянуть в дистрибутиве свою версию libstdc++, но это будет такой геморрой, что никто с этим связываться не будет.
Последний оплот GCC - это его поддержка разных платформ/архитектур, но и тут он долго не продержится против LLVM. Просто посмотрите на темпы развития последнего - там кипит реальная работа!
раненый GCC стыдливо зализывает раны прячась в естественных складках местности :)
>Последний оплот GCC - это его поддержка разных платформ/архитектур, но и тут
>он долго не продержится против LLVM. Просто посмотрите на темпы развития
>последнего - там кипит реальная работа!Когда начнут поддерживать компиляцию для армов как в Thumb так и в обычный код, тогда и поговорим
Черт. А у меня работает кодогенерация как в Thumb, так и в Thumb2. ЧЯДНТ?
>Черт. А у меня работает кодогенерация как в Thumb, так и в
>Thumb2. ЧЯДНТ?возможно это я недостаточно информирован.
>он долго не продержится против LLVM.Угу, только тут в соседней новости интель кодогенерацию под свои процессоры приперся затачивать. В GCC, да. И кстати когда ваш LLVM сможет генерить нормальный код для 8-битных AVRов например? Ну или накукуй мне изучать два (или эн) тулчейна(ов) если можно изучить один, при том НИЧЕГО не проиграв (достаточно бенчей на форониксе посмотреть, хаха - часть тестов совсем завалено, часть слито в хлам, остальное на примерно том же уровне ... и в чем профит и для кого, кроме Эппла?).
для avr, gcc порой генерит настолько наркоманский код, что волосы становятся дыбом.
>для avr, gcc порой генерит настолько наркоманский код, что волосы становятся дыбом.Да собссно любой компилер временами генерит адский ужас и протупляет. И что? В среднем по больнице - генерация кода у GCC на уровне прочих. Плюс-минус лапоть разумеется. Зато есть сильный плюс - один и тот же тулчейн а не 100500 разномастных. Ну и как бы а ваши предложения - ну допустим надо мне фирмвару для аврки. Сегодня, а не через 20 лет, блин. Через 20 лет я эти аврки уже не найду кроме как в музее. Чем еще ее сгенерячить? Ну разве что коммерческим компилером. Вот только смысл то? Они обычно только под винды, которые я в гробу видал. Стоят баблосов. Завязка на 1 вендора. И, черт возьми, осваивать еще один тулчейн с их тараканами и особенностями. Напуркуа весь этот геморрой если можно взять банальный GCC и ни в чем таком особо не проиграть, поюзать бесплатный линух, компилер и получить результат который вполне себе на уровне? Да еще и в ОС такой же. И прочая. Изучить один тулчейн проще чем 100500 разных...
AVR Studio ощутимо удобнее, нежели gcc-toolchain. Но под windows, так что если хочешь avr и linux - то тут только gcc.Большая часть тех, кто пишет под avr сидит под виндами, не столько из-за компилятора, сколько из-за софта для проектирования. Им этот gcc-avr назрен не сдался.
> Ну или накукуй мне изучать
>два (или эн) тулчейна(ов) если можно изучить одинюзер а тебя не задалбливает изучать постоянно меняющееся линуксовое api ?
да хлебом не корми - дай поизучать драйвер-апи.
выж про него или как обычно - слышу звон, но не знаю где он?
>юзер а тебя не задалбливает изучать постоянно меняющееся линуксовое api ?Нет, не задолбало. Оно меняется только в ядре, и то не настолько уж и сильно, чтобы постоянно мне икаться (я что, суперавтор половины подсистем ядра чтоли чтобы меня это СИЛЬНО задевало?). А если кого задолбало - ну они юзают какойнить некроманский рхел/центос с 2.6.18 с его мегастабильным апи и аби.
А так - если посмотреть на допустим виндозу, так там вообще жопа та еще с апи для всяких там новых фич типа вайфаев и блутусов, GPS, работе с USB без попадоса на написон ядерного драйвера который потом еще и сертифицировать надо и прочего геморроя. Нет, конечно, можно и в виндозу припереть libusb но это не штатное апи виндозы почему-то. А штатно, извините, надо драйвер ядра писать который мало того что писать геморно так потом еще и сертифицировать и подписывать усрешься нафигъ. И видеодрова в виндозе переколбасили. На свой зад, заметьте: как минимум интельское видео в всех осях начиная с висты стало весьма глюкавым и висючим. В итоге в винде до сих пор нет никакого стандартного метода расшарить GPS приемник на несколько программ, родной блутусный стек адски крив а другие - вывешивают иное апи и почему-то почти весь софт хочет стек от widcomm а не майкрософт. И так далее. А так - у какогонить MSDOS апи конечно стабильное. А толку? :)
Кайф. На http://clang.llvm.org/cxx_status.html посмотреть - сразу приятно на душе становится - прям все net-gen инструменты для создания приложений на одной странице - clang+llvm, cmake, qt. Будущее реально за ними, а не жавой и моно.
За этими наименования спрятался самый главный зверь - С++. За ним не должно быть будущего у прикладного программирования.
Угу, конечно, ведь микрософт корпорейшн вещает что сишарп рулит, да? Правильно я понимаю что вы их ручное трололо? По векторам троллинга и их откровенным нестыковкам - похоже :)
Будущее не за жабой - точно. Но вот про моно я б так не говорил. Да и .NET - это такой серьёзный и долгосрочный паровоз, что вопрос смерти Сипипей - 3-5 лет (да они уже сливают по всем показателям, кроме скорости кода).
Для прикладухи уже очевидна нецелесообразность прыганья вокруг "крутостей" Сипипи - цэшарп рулит нипадеццки, давая свободу мышлению и избавляя от низкоуровневых глупостей.
>Будущее не за жабой - точно. Но вот про моно я б
>так не говорил. Да и .NET - это такой серьёзный и
>долгосрочный паровоз, что вопрос смерти Сипипей - 3-5 лет (да они
>уже сливают по всем показателям, кроме скорости кода).
>Для прикладухи уже очевидна нецелесообразность прыганья вокруг "крутостей" Сипипи - цэшарп рулит
>нипадеццки, давая свободу мышлению и избавляя от низкоуровневых глупостей.Ой-ёй-ёй, C++ обречён. :) Уже сколько его хоронили Явами, Сишарпами, Перлами, ан живой почему-то.
У C++ своя ниша. Намного меньше, чем обычно кажется. C++ — инструмент для решения крайне нестандартных задач — когда приходится соединять несоединимое, и прямой доступ к системным сервисам сочетать с каким-нибудь XSLT. Лет двадцать назад Страуструп сам говорил, что C++ реально нужен единицам, что остальные используют его не по назначению. :) С тех пор много воды утекло, С++ развивался: появились шаблоны (круть-круть-круть), ссылки (прощай, NULL!) расширились стандартные и просто популярные библиотеки… Но язык по своей сути так и остался нишевым. Для тех, кому нужны «низкоуровневые глупости» (читай: строгий контроль над выполнением программы) в сочетании с высокоуровневыми интерфейсами. В Qt, например, C++ уместен, а вот в драйвере видеокарты или web-интерфейсе уже не очень (хотя встречается и там, и там).
Нету плохих и хороших языков, есть задачи и есть инструменты для их решения.
Судя по всему это будет убийца GCC, причем уже в ближайшем будущем. Архитектура у Clang/LLVM лучше, и это уже видно по темпам разработки. Не однократно писали, что у GCC уже слишком старый и запутанный код, который сложно развивать.
Жаль только, что его полностью контролирует (и разрабатывает) Apple. Т.е. для своих коммерческих продуктов им ничто не будет мешать встраивать проприетарные killer-фичи.
>Судя по всему это будет убийца GCC, причем уже в ближайшем будущем.Какие оптимисты. А интель что-то не в курсах.
>Архитектура у Clang/LLVM лучше, и это уже видно по темпам разработки.
А как одно коррелирует с другим?
>у GCC уже слишком старый и запутанный код, который сложно развивать.Ну так где же результаты развития? Бенчи на форониксе как-то ничего интересного не показали. А активную разработку саму по себе как бы в девайс не зальешь, на винч не установишь и прочая. И как бы еще хрен бы его знает что там в супер-дупер архитектуре выйдет на практике. Жабисты вон тоже орут о немеряных возможностях оптимизации. А на практике - понятно чего :). В итоге - вот когда будут результаты достойные восхищения - тогда и вопите, чтоли.
>Жаль только, что его полностью контролирует (и разрабатывает) Apple. Т.е. для своих
>коммерческих продуктов им ничто не будет мешать встраивать проприетарные killer-фичи.Хреновее то что данная конторка засветилась на открытии-закрытии своих проектов. А вот заявят однажды "ой, наш компилер используют пользователи хакинтошей!" и закроют нафиг. Попутно сделав ядро (которое тоже закрывали пару раз) собираемым только этим компилером. А почему нет? Глядя на условия япплосторов от эппл еще и не такое можно ожидать. Весьма злой и стремный проприетарщик.
Тебе вроде объяснили уже, паранойа по поводу Эппл это глупо. Но ты воспользовался тем, что те комментарии потерли и опять "проповедуешь" свою религию. Нехорошо.
>Жаль только, что его полностью контролирует (и разрабатывает) Apple. Т.е. для своих
>коммерческих продуктов им ничто не будет мешать встраивать проприетарные killer-фичи.На самом деле нет, проект полностью открыт и доступен с самого начала разработки. Хотя Apple да, спонсировала разработку, но не больше. Core-team большей частью работает не в Apple. Разработка вообще большей частью прошла в университете Иллинойса как исследовательский проект.
Еще один камень в огород GCC. Все знакомые, которые занимаются разработкой своих экспериментальных языков используют LLVM в качестве кодо-генератора. О чем-то это говорит. Никто даже близко не рассматривает GCC, ибо это ужас на крыльях ночи. Поэтому GCC в этом плане практически мертвый.
>Еще один камень в огород GCC. Все знакомые, которые занимаются разработкой своих
>экспериментальных языков используют LLVM в качестве кодо-генератора. О чем-то это говорит.
>Никто даже близко не рассматривает GCC, ибо это ужас на крыльях
>ночи. Поэтому GCC в этом плане практически мертвый.Ну это изобретатели велосипедов, с ними все понятно, но gcc. почему то, используется для сборки большинства дистрибутивов, интерсно, есть хоть один рабочий дистр, собранный с помощью сабжа?
>интерсно, есть хоть один рабочий дистр, собранный с помощью сабжа?Не удивлюсь, если ПОКА нет (среди линуксов. Но какая-то из БЗДей уже делает попытки) - людям всё же нужны работающие пакеты, а не "перспективные компиляторы". Но если уж такие гранды как ведро БЗД и буст собираются, значит переход уже можно даже форсировать - раздавать базовую Линукс-систему с CLang и пинать разрабов, чтобы те подточили сорсы под новый компилер (заодно, отсеются протухшие пакеты). "А там, глядишь, и в космос рванём!" (ц)
Если clang начнет собирать линуксовое ядро - будет замечательно. Без этого смерть gcc так же далека, как виндокопец.