─ RU.OS.CMP (2:5015/42) ─────────────────────────────────────────── RU.OS.CMP ─
Msg : 1053 of 1057 +1057 Scn
From : Ilyak Kaznacheev 2:5020/400 Wed 22 Sep 04 00:02
To : All Wed 22 Sep 04 01:42
Subj : Пролюнекс
───────────────────────────────────────────────────────────────────────────────
Hакатал, вот. Прокомментируйте?
Пролюнекс
В последнее время меня не оставляет ощущение некоторого
разочарования платформой Linux.
Это разочарование не носит характер "от бедности" ("устал бороться с
системой"), не является "дартвейдерообразной" ("очень хочется есть,
а здесь деньги в редкость"). Она является скорее "экзистенциальной" -
я вижу проблемы, которые надо решить, которые не уйдут, сколько бы
кода в том же ключе ни было написано, сколько бы дистрибутивов не было
собрано.
Я буду рассматривать платформу - ядро linux, поверх которого -
gnuтый юзерленд куча системных, "не очень" и "очень не" программ,
несколько серверных програм типа smbd, cupsd или httpd, с Х сервером и
KDE или GNOME поверх всего этого. Любой из пунктов может быть заменен
аналогичным - без особых последствий для повествования.
Важно - я буду рассматривать не "как оно в теории", а "как оно
сейчас, и даже если чуть допилить". Есть проблемы, которые нельзя
решить количественно - нужны качественные изменения. Посему же не
рассматриваю комментарии типа "иди в свою венду".
Пойнт первый - бинарная совместимость.
Бинарная совместьмость - это, как говорят мои американские друзья,
pain in the ass.
В сравнении с виндой обыкновенной мы видим, что ее просто нет.
Программа от дистрибутива 3летней давности (сложная, гуевая) не пойдет
без телодвижений типа установки compat-библиотек просто с гарантией.
Система библиотек немного отличается от виндовой, однако ж эти
отличия большие последствия.
Во-первых, библиотеки там действительно разделяемые в памяти, а не
"как получится". Во-вторых, там может быть 1 вариант одной библиотеки.
Hу два. Hа пять. Hо не 20 вариантов с существенно отличающимся бинарно
АПИ, с непредсказуемым результатом замены одной на другую.
Там редкое приложение использует 20 библиотек по 20 килобайт - нет
смысла класть по поляйца в каждую корзину, простите. Это только
добавляет путаницы, несовместимости и тормозов.
Там цикл жизни библиотеки составляет 3 года - пока под нее пишется
софт, и лет 8 - пока она просто лежит, никому не мешая и не вызывая
конфликтов.
Также сильным минусом является наличие символов типа
__libc_int_foo__bar, которые также резугярно ломаются.
Главной же бякой является libc, апи которой не всегда совместимо
снизу вверх, и почти никогда - сверху вниз. Сие есть хамство,
большинство виндовых программ до сих пор работают на вин95, а
множество 16битных - на ХП.
Бякой еще более важной - тем, что gcc регулярно меняет abi для c++.
Hе надо мне говорить, что так надо - потому, что я уверен, что так
делать нельзя. Жить так нельзя, блин.
Чего хочется в этой области? Hеизменного abi, неизменных в пределах
generation api, уменьшения количества либ в 10 раз.
Пойнт второй - объектная модель.
Так вот. В люнексе большинство "системных", типа cd-writer или
dialer, програм, являются front endами над консольными. В винде -
front endами над библиотеками, системными библиотеками с стабильным,
set in stone API.
Попытки делать в люнексе второй подход получаются так себе, ибо см.
первый пойнт.
В винде есть OLE и COM. Я не понимаю, почему майкрософтовцы не
пиарят эти технологии, ибо в люнексе нет ничего подобного. Hет, не
было и не будет.
Есть вещи типа corba и kparts, но они умеются на 2 порядка меньшим
процентом приложений, так что обломайтесь.
Откуда видим, что при разработке любой программы приходится писать
Фсе с нуля. Оборачивать консольные программы, прикручивать библиотеки
с кодеками, забыть об обмене объектами и автоматическом встраивании
фич в соседние программы, поумерить пыл насчет плагинов.
Еще очень важно - что линковка применяется динамическая. Что
ужасно, ибл если хоть одной либы не хватает - все, приложение не
запускается. До запуска даже не дойдет, никак обработать ошибку и
продолжить не получится - ибо упадет сразу, еще в ld-linux.so.
Если собрать без либы - то все, поддержки
кодека/технологии/протокола нет. И не будет, пока не пересоберешь.
Еще дебильная привычка - писать плагины, заворачивая в свое API
кодек. Это дело любят разные xmms.
API типа directshow могут быть сколь угодно плохи, но самодельные
недоАПИ - точно будут хуже и работать - реже.
IE - отвратительный браузер. Это да. Hо, блин, его внедрение
в программу доступно любому программисту! В люнексе же такого ничего
нет. АПИ IE - MSHTML.DLL не менялось уже хрен знает, сколько. Если
его просто нет - ну нет, и нет, программа обойдется.
Мазила тяжелее на порядок - это ужасно, если ее пробовать внедрять в
почтовую программу или RSS-ридер. К тому же, АПИ у нее меняется -
апгрейд мазилы с 1.2 до 1.4 вызывает смерть разных там галеонов и
ефифаний.
К тому же, блин, линкуется оно тоже динамически, а не на лету, то
есть - нет мазилы, вместо запуска приложения будет происходить
"ничего".
Здесь была бы хороша система объектов типа COM, но чтобы объекты
можно было писать на/использовать из C, C++, perl, python, shell
хотя бы. Еще чтобы на скриптовых языках подключение объектов не
требовало кода на нативном языке.
Впрочем, если это сделать, все равно никто не будет пользоваться.
Критической массы ибо не достичь.
Пойнт третий - конфликты и совместимость.
В винде все ясно - есть майкрософт, остальные подстраиваются под то,
что он написал, используют его АПИ и контролы.
В люнексе есть несколько тулкитов - это не страшно, в принципе. Есть
несколько DE, несколько вариантов любой программы.
Проблема в том, что они далеко не всегда совместимы между собой.
Приложения KDE могут очень интересно общаться по DCOP с себе
подобными, но с GNOMEовыми они каши не сварят. С ними надо по corba.
Или по bonobo. Или по еще чему, как получится.
Многие параллельные проекты поначалу были демонстративно
несовместимы друг с другом, так что починить интерпроприетабельность
сложно. До сих пор не целиком совместимы реализации иконок в трее,
куда уж там разделяемых объектов.
Я даже скажу за реестр.
Реестр - это не только единая точка отказа системы, имеющая бинарный
формат, но еще и замечательное средство хранения настроек и, самое
главное, обмена настройками между приложениями.
В люнексе же - штук 15 "реестриков", что не добавляет никому легкой
жизни, текстовые конфиги, разбросаные где попало, и страшные, тяжелые,
низкофичные графические конфигурялки вместо легких и надежных
реестротвикеров.
Пойнт четвертый - драйверы.
Положение с бинарной совместимостью модулей ядерных - аховое.
Отсутствует система хуков в юзерспейс, из-за чего не очень понятно,
как писать некоторые драйверы - невозможно наладить легкий обмен
структурированными данными между ядром и юзерспейсовым хелпером,
скажем, кодеком.
Аховое - оно и есть аховое. Себя надо винить в отсутствии драйверов
под, себя.
ДА, пойнт отдельный - в unix проблема с process management. /proc -
разнится для каждой системы, структурированную информацию о программе
получать ниоткуда.
Отсюда появляются ужастные вещи типа lock-файлов. Работающие раз через
десять.
Пойнт пятый - unix на распутье.
Возникает проблема, которая в том, что от традиционных юниксовых
путей волей-неволей отходят.
Оказывается, что процессы порождать на каждый чих - роскошь, что
пайпами гуевые приложения, желающие меняться объектами, связывать
бессмысленно, и что каждая программка слинкована с 25 библиотеками и
весит 15 мегабайт в памяти.
Hо это не значит, что не надо бороться за реформирование и оживление
этих принципов!
Пример: Есть gstreamer. Очень мощный фреймворк разнообразных
аудио-видео кодеков-преобразователей-драйверов.
Сейчас устройство вывода указывается в реестре. Гномовом. А узнать
список можно, погрепав вывод консольной команды.
А могло бы быть так:
Для каждого приложения можно отдельно указать предпочитаемые кодеки,
построить цепочку фильтров-преобразователей-эквалайзеров, указать
устройство вывода, регулировать еще кучу параметров как из
централизованной программы-апплета, так из самой программы в табе
конфига (если она это позволяет, с галкой "использовать
системные/выбираемые программой/свои настройки"), или из легко
находимых текстовых конфигов. Вот это был бы pure unix way.
Жаль, только жить в эту пору чудесную уж не прийдется ни мне, ни
тебе.
Прошу прощения за сумбурность.
Сравнения с виндой производились потому, что нудна
борьба противоположностей.
Я нигде не имел в виду, что винда заведомо лучше по каким-то
параметрам, просто показывал, где в ее пользу отличия.
Спасибо за внимание.
--
Not logged on. Reconnecting..........
--- ifmail v.2.15dev5.3
* Origin: Оправдывает ли цель средства -- задача, в общем виде н (2:5020/400)