> А в моем понимании в подобных вопросах надо смотреть на качество конкретного
> кода, а не на названия брендов.

А четкие критерии качества - можно в студию? Кстати да, для *кодека* требование вида "строгий ANSI C" - не обязательно катят. Если вам кодек H.264 на строгом анси цэ написать, без асмовых кусков (которые по определению не описаны в стандартах на си) - вы же и будете рыдать от производительности такого кодека.

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

Отлично. Но вы даже не обругали нормально фичи. Более того - вы как-то упустили моменты что бывают нужные фичи которые по определению специфичны для компилера/набора тулсов, но тем не менее нужны. Например, как-то так уж вышло что стандарты не определяют например как делать в сишную программу асмовые вставки. И еще немало моментов.

> Просто некоторых очень беспокоит, что появились возможности не пользоваться gcc, и этих
> возможностей становится все больше и больше в самых разных проектах.

Я вижу даже некий плюс - GCC явно не помешает пинок для ускорения развития :-).

> Я вообще-то говорил об отдельных частях Линукс-ядра, а не об ядре в целом.

Ну, кому надо - может ипстись с выборкой из ядра "неправильных" кусков. Мне не жалко. А у меня и более интересные дела есть. Подозреваю что у аффтаров майнлайнового ядра - тоже.

> Или для вас часть эквивалентна целому? Либо все, либо ничего?

Ядро поставляется как некий продукт. Дальше я выбираю какие его субкомпоненты мне нужны. И мне как-то ну совсем не прикольно выкидывать компоненты не потому что "так лучше" и "это хорошо для решения задачи", а потому что ... "компилер не может это сжевать". А зачем мне геморрой на ровном месте? oO

> Как-то ну совсем нелогично, вы не находите? oO

Нет, я не нахожу. Если мне приспичило пересобрать ядро - то по каким-то веским причинам, к которым расовая (не)верность компилеров ни разу не относится. Благо, я ни разу в жизни не ощущал на своем заду никаких ограничений от гцц, даже собирая им нахрен проприетарную фирмварину защищенную от чтения, что вполне допустимо его лицензией. А возможность всяких там япплов зажопить код инструментария и устроить всем при случае кидок а-ля дарвинское ядро меня как-то интересует вообще в последнюю очередь. Я просто в меру возможностей не буду закладываться на тулзы которые зависят от 1 коммерческой конторы - нафиг-нафиг лишние риски. Вон жабисты уже на своем заду ощущают последствия такой практики :-).

> Ведь бо'льшая часть Линукс-ядра ведь уже собирается с помощью clang.

Есть такая весьма правдивая байка, которая гласит что 80% работы обычно делается за 20% времени. Весь компот портят остальные 20%, на выполнение которых уходит оставшиеся 80% времени :)

> Вот еще бо'льшую часть кода binutils и coreutils соберут (а во FreeBSD
> их аналоги уже собрали).

Шланг с бинутилсами? Это видимо из разряда "без порток, а в шляпе". Благо бинутилсы тоже под расово-неверной лицензией, вызывающией батхерт у бсдшников и эппла. :)

> И ничто не помешает создавать дистрибутивы Линукса, полностью основанные на clang.

Как бы флаг в руки тем кому это надо. Будет любопытно посмотреть на то что получится.

> А те исключения кода (кода, а не проекты целиком), что не соберутся
> - анализируются, почему не собрались. И что лучше в каждом конкретном
> случае - добавлять в clang какую-то сомнительную фичу, или просто заменить
> фичу в конкретном проекте.

Ну, как бы, вы не можете диктовать всем авторам проектов что им и как делать и за них решать - нужна им та или иная фича. ИМХО, с практической точки зрения - допилить 1 компилер явно проще чем сотни тысяч программ по всему миру.

> Взять хотя бы SELinux. Система громоздкая и неуклюжая. Еще польшой вопрос, стоит
> ли беспокоиться о ее поддержке новым компилятором.

Мне он не нравится. Как раз этим самым. Мне проще сделать сравнимую изоляцию и паранойю совершенно иными методами. Однако редхатчики и федористы вас имхо не поймут. Кроме того, серьезные (гос)конторы и т.п. имеют как правило вполне конкретный регламент работы с секретными документами, где четко прописаны все процедуры. Регламент большинства таких контор - явно требует обязательное наличие системы мандатного контроля доступа (как минимум, у нас и в сша оно АФАЙК вот так, да и другие наверное не сильно отличаются). Без реализации системы мандатного контроля доступа ваша система просто-напросто никогда не попадет в такие конторы, не пройдя сертификацию. А это как ни крути - один из рубежей признания системы "взрослой". Это, конечно, формальности, однако ж появились они в таких конторах не просто так для красоты.

> С другой стороны сам Linux все-таки постепенно допиливают до модульной поддержки систем
> безопасности. Так что, глядя на новый модульный компилятор, у разработчиков Линукса
> будет лишний повод задуматься об архитектуре ядра.

У меня почему-то такое ощущение что они не будут сильно дергаться ради поддержки какого-то (довольно сырого) компилера неизвестно ради чего. В мире как бы много разных компилеров. На все все-равно не надергаешься. Например, есть ICC. Некоторые джедаи им даже что-то собирают. Однако врядли кого в майнлайне интересует объем потребных для этого плясок. Особенно когда интель сам в гцц впихивает патчи для улучшения поддержки своих процов т.к. ему это тоже стало надо :)

>> И что же НЕМИНУЕМО сподвигнет разработчиков? Нож? Или пистолет? oO
> Общие тенденции в сторону повышения модульности и гибкости при проектировании.

А в каком месте упомянутые факторы гарантируют какую-то там неминуемость чего либо? И откуда это следует?

> равносильно ножу или пистолету.

Только для школоло, бегающих за тенденциями и модой.