диктатура меньшинств (компьютерное)
Jun. 2nd, 2005 03:53 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaUlrich Drepper: Dictatorship of the Minorities
Дреппер работает в RedHat и знаменит в первую очередь поддержкой и разработкой в последние годы glibc - главной C-библиотеки проекта GNU, использующейся в первую очередь в Линуксе.
В этой заметке он пытается убедить open source-разработчиков не поддерживать странные, редкие или коммерческие OS и архитектуры, а поддерживать, по сути дела, только Линукс, да и то лишь несколько основных компьютерных архитектур, на которых бежит Линукс, а не всех.
По этому поводу разгорелся флейм у него в журнале и на Слэшдоте.
Дреппер, в общем, неумно очень написал, но некоторое рациональное зерно есть. Правда, у него оно погребено под стогом глупостей и злобных наездов на "чужие" платформы.
Как правильно заметили многие из ответивших ему, поддержка проекта для многих OS/архитектур очень часто помогает обнаружить баги/недостатки дизайна, не столь очевидные в случае, если вести его только на одной/двух платформах. Примеры многочисленны и очевидны. 32-битные/64-битные архитектуры. Платформы, на которых int==long, и на которых они различны. OpenBSD славится параноидальным подходом ко всему, включая, например, защиту адресного пространства, так что обращение по испорченному указателю с большей вероятностью повалит программу (и хорошо). Различия в абстрагировании "железа" и том, как уровни абстракции устроены... и так далее, и тому подобное.
Но есть и другие виды межплатформенных различий, которые, при попытке поддерживать проект на разных платформах, вызывают лишь раздражение, а пользы никакой не приносят. Сюда в первую очередь относятся мелкие и тонкие различия в стандартных библиотеках разного рода. Принципиальное несовершенство архитектуры (та же проблема 8.3 в файловых именах или неразличение регистра в них же). Принципиальная маломощность платформы (16-битные платформы те же). Мелкие несовместимости на уровне OS (скажем, различия в семантике сигналов). Отсутствие библиотеки на одной из платформ, в то время как та же библиотека есть на всех остальных (и переноси теперь её сам или калечь свой проект, пытаясь предоставить возможность обходиться без неё). И многое ещё.
Проблема в том, что Дреппер не делает различия между этими двумя источниками проблем, а точнее, все такие проблемы считает ненужной головной болью. Действительно, если писать только под Линукс, под 1-2 главные архитектуры, то их не будет. Правда, все недостатки, которые проблемы первого рода помогают обнаружить, останутся, и многие из них рано или поздно всплывут. Правда, такое поведение аналогично поведению тех, кто пишет только под Windows, и кого Дреппер считает "pure evil". Но такие противоречия в своём манифесте Дреппера не смущают. "I don't care and I certainly won't change my mind on this."
В общем, и на glibc это проливает некоторый свет. glibc - ужасно написанная и скомпонованная библиотека. Просто с точки зрения того, как устроены исходники, как найти нужную функцию и что-то понять/добавить/изменить, как она строится. Если бы она хотя бы поддерживала десятки платформ (как первоначально рассчитывали), эта сложность и запутанность была бы ещё хоть в какой-то мере оправдана. Но, оказывается, под руководством Дреппера всё свелось к поддержке одного лишь Линукса (и частично Хурда), и то не на всех архитектурах. Жалкое зрелище, и не очень понятно, зачем она тогда нужна. Истинно вам говорю, тот, кто видел и копался в исходниках libc под FreeBSD и под Линуксом - не задумываясь ни на секунду, выберет BSDшную библиотеку.
Дреппер работает в RedHat и знаменит в первую очередь поддержкой и разработкой в последние годы glibc - главной C-библиотеки проекта GNU, использующейся в первую очередь в Линуксе.
В этой заметке он пытается убедить open source-разработчиков не поддерживать странные, редкие или коммерческие OS и архитектуры, а поддерживать, по сути дела, только Линукс, да и то лишь несколько основных компьютерных архитектур, на которых бежит Линукс, а не всех.
По этому поводу разгорелся флейм у него в журнале и на Слэшдоте.
Дреппер, в общем, неумно очень написал, но некоторое рациональное зерно есть. Правда, у него оно погребено под стогом глупостей и злобных наездов на "чужие" платформы.
Как правильно заметили многие из ответивших ему, поддержка проекта для многих OS/архитектур очень часто помогает обнаружить баги/недостатки дизайна, не столь очевидные в случае, если вести его только на одной/двух платформах. Примеры многочисленны и очевидны. 32-битные/64-битные архитектуры. Платформы, на которых int==long, и на которых они различны. OpenBSD славится параноидальным подходом ко всему, включая, например, защиту адресного пространства, так что обращение по испорченному указателю с большей вероятностью повалит программу (и хорошо). Различия в абстрагировании "железа" и том, как уровни абстракции устроены... и так далее, и тому подобное.
Но есть и другие виды межплатформенных различий, которые, при попытке поддерживать проект на разных платформах, вызывают лишь раздражение, а пользы никакой не приносят. Сюда в первую очередь относятся мелкие и тонкие различия в стандартных библиотеках разного рода. Принципиальное несовершенство архитектуры (та же проблема 8.3 в файловых именах или неразличение регистра в них же). Принципиальная маломощность платформы (16-битные платформы те же). Мелкие несовместимости на уровне OS (скажем, различия в семантике сигналов). Отсутствие библиотеки на одной из платформ, в то время как та же библиотека есть на всех остальных (и переноси теперь её сам или калечь свой проект, пытаясь предоставить возможность обходиться без неё). И многое ещё.
Проблема в том, что Дреппер не делает различия между этими двумя источниками проблем, а точнее, все такие проблемы считает ненужной головной болью. Действительно, если писать только под Линукс, под 1-2 главные архитектуры, то их не будет. Правда, все недостатки, которые проблемы первого рода помогают обнаружить, останутся, и многие из них рано или поздно всплывут. Правда, такое поведение аналогично поведению тех, кто пишет только под Windows, и кого Дреппер считает "pure evil". Но такие противоречия в своём манифесте Дреппера не смущают. "I don't care and I certainly won't change my mind on this."
В общем, и на glibc это проливает некоторый свет. glibc - ужасно написанная и скомпонованная библиотека. Просто с точки зрения того, как устроены исходники, как найти нужную функцию и что-то понять/добавить/изменить, как она строится. Если бы она хотя бы поддерживала десятки платформ (как первоначально рассчитывали), эта сложность и запутанность была бы ещё хоть в какой-то мере оправдана. Но, оказывается, под руководством Дреппера всё свелось к поддержке одного лишь Линукса (и частично Хурда), и то не на всех архитектурах. Жалкое зрелище, и не очень понятно, зачем она тогда нужна. Истинно вам говорю, тот, кто видел и копался в исходниках libc под FreeBSD и под Линуксом - не задумываясь ни на секунду, выберет BSDшную библиотеку.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2005-06-02 01:31 pm (UTC)PS Да и я держу исходники netbsd как reference ;) Если надо понять например, как работает какая нибудь железка или файловая система --- там гораздо более чистый и понятный код. (Правда эти граждане могут позволить себе рефакторинг архитектуры чуть ли не раз в год)
no subject
Date: 2005-06-02 02:10 pm (UTC)При том, что API ядра меняется с каждой минорной цифрой.
no subject
Date: 2005-06-02 02:17 pm (UTC)Потому как чем иначе объямснить излишки copy-paste, --- в ядре вроже до сих пор 3 экземпляра zlib закопано, и явно не одна реализация шины pci и полторы ext2/3
no subject
Date: 2005-06-02 02:18 pm (UTC)Это прекрасно, конечно, если так ;)
no subject
Date: 2005-06-02 02:32 pm (UTC)Тем не менее мне нравится как в netbsd любой код общий для двух и более архитектур выносят в отдельный модуль.
no subject
Date: 2005-06-05 11:30 pm (UTC)no subject
Date: 2005-06-02 02:31 pm (UTC)Похоже что надо брать какую-нибудь dietlibc и раскармпливать до нормальных размеров. А то что за система на которой нихрена статически собрать нельзя - ресолвер работать не будет.
no subject
Date: 2005-06-02 05:35 pm (UTC)no subject
Date: 2005-06-02 06:48 pm (UTC)Тем не менее, по существу - согласен.
no subject
Date: 2005-06-03 12:03 am (UTC)no subject
Date: 2005-07-03 09:31 pm (UTC)