Попытаюсь ответить, несмотря на то, что вопрос адресован не мне.

С моей точки зрения, просирание полимеров заключается, главным образом, в двух вещах (во многом взаимосвязанных): чересчур возросшей сложности современных дистрибутивов GNU/Linux (десктопный линукс стремительно приближается по этому показателю к венде, и наличие исходников помогает все меньше и меньше) и крайне плохой масштабируемости базарной модели разработки (в терминах ESR). Попытаюсь разобрать.

Bazaar (в данном случае я говорю о inter-project collaboration, а не intra-) работал, пока проектов было немного (kernel, glibc, binutils, coreutils, fileutils и прочий немногочисленный юзерленд). Платформа тогда была по сути одна (плюс несколько embedded, но они изначально были в маргинальном положении, а затем окончательно лишились какой-либо официальной поддержки "центра" – чтобы представить себе картину бедствия, можно почитать каменты Дреппера в багзилле glibc о том, что он думает по поводу "embedded crap"; на /. был хороший тред по этому поводу).

Со временем, когда параллельно усложнялись ядро, глибц, peripheral stacks, которые являются (важно!) независимыми проектами со своими отдельными разработчиками, багзиллами, релиз-циклами и пр., координировать разработку и поддержку более-менее "нормального" дистрибутива становилось все сложнее. Когда-то на старом дебиане или редхате можно быть спокойно скачать ванильное ядро с кернел.орг, собрать его, и все бы работало (с ABI compatibility у линукса всегда было хорошо). Сейчас же ядро от вендора – это десятки патчей. То же самое с glibc и прочим. Котовасия последних лет с devfs/udev и планировщиками привела к тому, что каждый вендор останавливался на какой-то одной комбинации и поддерживает ее уже самостоятельно, in-house, стараясь, чтобы оно все вместе как-то работало у большинства пользователей. У крупных вендоров (RedHat, SuSE, Ubuntu), кто может позволить себе держать нехилый отдел QA, или у Debian (за счет более консервативной разработки, строгой политики и ориентированности на продвинутого пользователя) это пока получается. А маргинальным дистрам вроде слаквари проще "выкинуть гном". Поддерживать современный набор софта в модели базара очень тяжело: из-за низкого качества, плохой координации и отсутствия единого вектора развития thereof.

Кстати, интересное наблюдение: есть мнение (и весьма справедливое), что сборка cross-compilation toolchains на основе binutils, gcc и glibc – занятие неблагодарное и муторное. Обеспечить сколько-нибудь широкий coverage (т.е. матрицу комбинаций различных версий компонент) задача не из простых: придется постараться, чтобы, скажем, glibc 2.3.6 собирался gcc 4.5.0 для арма. Здесь и чтение сорцов, гугл, блуждание по багзиллам glibc и gcc, и изучение патчей открытых тулчейнов – я, кроме прочего, в частности этим занимаюсь at $dailyjob.

Интереснее всего то, к чему это привело: сейчас для embedded разработки тулчейн проще купить, чем собирать самому. Т.е., натурально: конторы (типа той же CodeSourcery) делают профит на сложности интеграции opensource софта, причем не сложности per se, а сложности, проистекающей из-за крайне плохого взаимодействия между разработчиками и явно недостаточной координации их усилий. Это, по-моему, вообще epic fail.

(Reply to this) (Parent)