?

Log in

No account? Create an account
диктатура меньшинств (компьютерное) - Поклонник деепричастий [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

диктатура меньшинств (компьютерное) [июн. 2, 2005|03:53 pm]
Anatoly Vorobey
Ulrich 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шную библиотеку.
СсылкаОтветить

Comments:
[User Picture]From: avnik
2005-06-02 01:31 pm
Я уже раз несколько натыкался на то, что всякие мелкие проекты (типа мигроядерных изысков) использовали libc от netbsd, видимо за портабельность и прозрачность.

PS Да и я держу исходники netbsd как reference ;) Если надо понять например, как работает какая нибудь железка или файловая система --- там гораздо более чистый и понятный код. (Правда эти граждане могут позволить себе рефакторинг архитектуры чуть ли не раз в год)
(Ответить) (Thread)
From: 9000
2005-06-02 02:10 pm
А почему линуксоиды не могут себе этого позволить?
При том, что API ядра меняется с каждой минорной цифрой.
(Ответить) (Parent) (Thread)
[User Picture]From: avnik
2005-06-02 02:17 pm
РЕлигия не позволяет.

Потому как чем иначе объямснить излишки copy-paste, --- в ядре вроже до сих пор 3 экземпляра zlib закопано, и явно не одна реализация шины pci и полторы ext2/3
(Ответить) (Parent) (Thread)
[User Picture]From: avva
2005-06-02 02:18 pm
3 экземпляра zlib? да ну? ;)

Это прекрасно, конечно, если так ;)
(Ответить) (Parent) (Thread)
[User Picture]From: avnik
2005-06-02 02:32 pm
zlib они таки да искоренили ;)

Тем не менее мне нравится как в netbsd любой код общий для двух и более архитектур выносят в отдельный модуль.
(Ответить) (Parent) (Thread)
From: nbuwe
2005-06-05 11:30 pm
Что-то я не припомню реафкторингов архитектуры каждый год. Наоборот, NetBSD во многих отношениях скорее консервативна.
(Ответить) (Parent) (Thread)
[User Picture]From: vitus_wagner
2005-06-02 02:31 pm
Дреппер — censored. Это было очевидно еще в 97-98 году когда в libc нормальную поддержку русской локали пропихивали. Как вспомню, как у него strcoll при сравнении пустых строк в корку падала...

Похоже что надо брать какую-нибудь dietlibc и раскармпливать до нормальных размеров. А то что за система на которой нихрена статически собрать нельзя - ресолвер работать не будет.
(Ответить) (Thread)
[User Picture]From: stas
2005-06-02 05:35 pm
Ну, даже если бы такое случилось, то и тогда на ближайшие лет 5 glibc - наш рулевой, разве что удастся создать совместимую на уровне API альтернативу (что сомнительно). А такое вряд-ли случится - кто ж в наше время libc переписывать станет? Это ж сизифов труд.
(Ответить) (Parent) (Thread)
From: vap
2005-06-02 06:48 pm
Ну, uClibc уже плюс-минус доросла до возможности собрать с ней base от Debian Woody.
Тем не менее, по существу - согласен.
(Ответить) (Parent) (Thread)
[User Picture]From: msh
2005-06-03 12:03 am
Интересно, это ему RedHat должен спасибо сказать за то, как они продули на рынке embedded, или он у них не одинок с такими взглядами?
(Ответить) (Thread)
[User Picture]From: egorfine
2005-07-03 09:31 pm
Ох... этот перец слабовменяем, по слухам коллег, пытавшихся его убедить привести в чувство кое-какую детальку в glibc. :-\
(Ответить) (Thread)