>Новых собственных инновационных идей у них нет а самовыразиться хочется. Вот и
>плодятся бесконечные переделки. Почти сорок лет всё вокруг Unix крутится потому-что
>мало кто способен посмотреть на неё свысока и увидеть её отсталость
>и врождённые недостатки типа "всё есть файл". Денис Ричи: "... есть
>другой подход - объектно-ориентированный когда каждый объект управления имеет свои специфичные
>методы ...".
Посмотрите Plan 9 для разнообразия.>Или этот Лайнус
>со своим девизом "единственно практически правильный путь - монолитное ядро". Ну
>хоть проект Hurd есть и то хорошо.
В проекте Hurd разброд и шатания. Ядра работоспособного и окружения, а так же фреймворка для драйверов просто напросто нет. Даже Haiku на их фоне смотрятся более перспективно и достойно.
> Пойнт первый - бинарная совместимость.
> Бинарная совместьмость - это, как говорят мои американские друзья,
>pain in the ass.
> В сравнении с виндой обыкновенной мы видим, что ее просто
>нет.
Надо не забывать одну вещь... больше 90% софта для linux так же для *BSD систем распрастраняется в виде исходников. Так зачем необходима бинарная совместимость ? Для получения dll hell?
>Программа от дистрибутива 3летней давности (сложная, гуевая) не пойдет
>без телодвижений типа установки compat-библиотек просто с гарантией.
А оно надо ? В таких программах четко указано какую версию дистрибутива использовать. Или какие библиотеки юзать.
> Система библиотек немного отличается от виндовой, однако ж эти
>отличия большие последствия.
Скажем не немного, а несколько подругому. И кстати с использованием пакетного менеджера все гараздо более управляемо чем в windows.
> Во-первых, библиотеки там действительно разделяемые в памяти, а не
>"как получится". Во-вторых, там может быть 1 вариант одной библиотеки.
>Hу два. Hа пять. Hо не 20 вариантов с существенно отличающимся бинарно
>
>АПИ, с непредсказуемым результатом замены одной на другую.
В windows может быть легко 20 вариантов библиотек. В любом нормальном дистрибутиве не больше 4. И то из-за требований совместимости. Я говорю про berkley db. Других библиотек в 20 кратном варианте я не припомню. Если можете припомнить укажите ее.
> Там цикл жизни библиотеки составляет 3 года - пока под
>нее пишется
>софт, и лет 8 - пока она просто лежит, никому не мешая
>и не вызывая
>конфликтов.
Вот из-за этого и возникает dll hell.
> Также сильным минусом является наличие символов типа
>__libc_int_foo__bar, которые также резугярно ломаются.
> Главной же бякой является libc, апи которой не всегда совместимо
>
>снизу вверх, и почти никогда - сверху вниз. Сие есть хамство,
>большинство виндовых программ до сих пор работают на вин95, а
>множество 16битных - на ХП.
Это и не требуется. Совместимость это палка о двух концах. Посмотрите сколько раз ломали совместимость и ничего. В linux так же. При использовании пакетного менеджера все работает как часы.
> Бякой еще более важной - тем, что gcc регулярно меняет
>abi для c++.
> Hе надо мне говорить, что так надо - потому, что
>я уверен, что так
>делать нельзя. Жить так нельзя, блин.
У меня есть около 10 систем которые это пережили без каких либо проблем. В чем проблема? Так сложно пересобрать приложение ? Или воспользоваться пакетным менеджером для обновления ПО и системы?
> Чего хочется в этой области? Hеизменного abi, неизменных в пределах
>generation api, уменьшения количества либ в 10 раз.
Уменьшения каких именно либ ?
> Пойнт второй - объектная модель.
> Так вот. В люнексе большинство "системных", типа cd-writer или
>dialer, програм, являются front endами над консольными. В винде -
>front endами над библиотеками, системными библиотеками с стабильным,
>set in stone API.
> Попытки делать в люнексе второй подход получаются так себе, ибо
>см.
>первый пойнт.
Бред, Это разница в подходах. В windows надо делать через библиотеки т.к. есть стандартное api в linux есть и приложения. Хотя у них тоже есть API.
> В винде есть OLE и COM. Я не понимаю, почему
>майкрософтовцы не
>пиарят эти технологии, ибо в люнексе нет ничего подобного. Hет, не
>было и не будет.
Еще раз напоминаю о разнице в подходах. Если брать linux или любой другой *nix как сервер то где его использовать.
> Есть вещи типа corba и kparts, но они умеются на
>2 порядка меньшим
>процентом приложений, так что обломайтесь.
Если рассматривать KDE и его приложения то они вполне сравнимы. Да может COM вещь полезная, но только в плане идеологии windows. Укажите мне куда нееобходимо размещать COM в linux ?
> Откуда видим, что при разработке любой программы приходится писать
>Фсе с нуля.
В каком смысле с нуля ?
>Оборачивать консольные программы, прикручивать библиотеки
>с кодеками, забыть об обмене объектами и автоматическом встраивании
>фич в соседние программы, поумерить пыл насчет плагинов.
Если вы будете использовать KDE и ее библиотеки нет никаких проблем.
Сравнивайте корректно.
> Еще очень важно - что линковка применяется динамическая. Что
>ужасно, ибл если хоть одной либы не хватает - все, приложение не
>запускается. До запуска даже не дойдет, никак обработать ошибку и
>продолжить не получится - ибо упадет сразу, еще в ld-linux.so.
В windows абсолютно так же.
> Если собрать без либы - то все, поддержки
>кодека/технологии/протокола нет. И не будет, пока не пересоберешь.
Сборка в static для вас пустой звук?
> Еще дебильная привычка - писать плагины, заворачивая в свое API
>кодек. Это дело любят разные xmms.
Не используйте xmms
> API типа directshow могут быть сколь угодно плохи, но самодельные
>недоАПИ - точно будут хуже и работать - реже.
Странно почему ffshow пользуются такой популярностью ? И работают быстрее стандартных виндовых кодеков ? Почему mplayer в X-window системе которая выводит тормознее чем windows работает быстрее windows media player ? Это отчетливо видно на старых машинах или при наложении фильтров.
> IE - отвратительный браузер. Это да. Hо, блин, его внедрение
>в программу доступно любому программисту! В люнексе же такого ничего
>нет. АПИ IE - MSHTML.DLL не менялось уже хрен знает, сколько. Если
>его просто нет - ну нет, и нет, программа обойдется.
А зачем его внедрять ? *nix другая идеология. Не консолидировать в одной программе все что можно, а использовать кучу мелких программ в различных последовательностях.
> Мазила тяжелее на порядок - это ужасно, если ее пробовать
>внедрять в
>почтовую программу или RSS-ридер. К тому же, АПИ у нее меняется -
>
>апгрейд мазилы с 1.2 до 1.4 вызывает смерть разных там галеонов и
>
>ефифаний.
> К тому же, блин, линкуется оно тоже динамически, а не
>на лету, то
>есть - нет мазилы, вместо запуска приложения будет происходить
>"ничего".
Ай-ай. Зачем это делать ? Вы мыслите десктопом, а не сервером. Для десктопа я бы вместо windows лучше буду использовать Mac OS X или на худой конец Haiku. В linux же стоит использовать полноценные среды. К примеру KDE.
> Здесь была бы хороша система объектов типа COM, но чтобы
>объекты
>можно было писать на/использовать из C, C++, perl, python, shell
>хотя бы. Еще чтобы на скриптовых языках подключение объектов не
>требовало кода на нативном языке.
> Впрочем, если это сделать, все равно никто не будет пользоваться.
Потому что это не имеет смысла.
> Пойнт третий - конфликты и совместимость.
> В винде все ясно - есть майкрософт, остальные подстраиваются под
>то,
>что он написал, используют его АПИ и контролы.
> В люнексе есть несколько тулкитов - это не страшно, в
>принципе. Есть
>несколько DE, несколько вариантов любой программы.
> Проблема в том, что они далеко не всегда совместимы между
>собой.
Недавно появился проект для избежания этого.
> Приложения KDE могут очень интересно общаться по DCOP с себе
>
>подобными, но с GNOMEовыми они каши не сварят. С ними надо по
>corba.
>Или по bonobo. Или по еще чему, как получится.
В скором времени когда проект api будет завершен и будет поддерживаться и KDE и Gnome проблемы исчезнут.
> Реестр - это не только единая точка отказа системы, имеющая
>бинарный
>формат, но еще и замечательное средство хранения настроек и, самое
>главное, обмена настройками между приложениями.
В результате он часто бывает сильно засорен.
> В люнексе же - штук 15 "реестриков", что не добавляет
>никому легкой
>жизни, текстовые конфиги, разбросаные где попало, и страшные, тяжелые,
>низкофичные графические конфигурялки вместо легких и надежных
>реестротвикеров.
Все конфигурационные файлы лежат в /etc все каталоги и имена файлов имеют вменяемые названия в отличии от параметров в реестре. Назовите мне хоть один действительно надежный и легкий реестротвикер. Которые в результате своей работы не ломают систему. Так же советуется посмотреть YaST.
> Пойнт четвертый - драйверы.
> Положение с бинарной совместимостью модулей ядерных - аховое.
> Отсутствует система хуков в юзерспейс, из-за чего не очень понятно,
>
>как писать некоторые драйверы - невозможно наладить легкий обмен
>структурированными данными между ядром и юзерспейсовым хелпером,
>скажем, кодеком.
Для файловых систем есть FUSE. Для всего остального хватает файла устройства. Все это очень хорошо работает. Чем вас не устраивает обмен с использованием ioctl + чтение запись в файл устройства ?
> Аховое - оно и есть аховое. Себя надо винить в
>отсутствии драйверов
>под, себя.
В чем аховое ?
>
> ДА, пойнт отдельный - в unix проблема с process management.
>/proc -
>разнится для каждой системы, структурированную информацию о программе
>получать ниоткуда.
> Отсюда появляются ужастные вещи типа lock-файлов. Работающие раз через
>десять.
?! Странно очень странно... то про api соловьем, то теперь про то что из proc плохо читать. Как-то даже странно... posix api посмотрите а ?
>
> Пойнт пятый - unix на распутье.
> Возникает проблема, которая в том, что от традиционных юниксовых
>путей волей-неволей отходят.
> Оказывается, что процессы порождать на каждый чих - роскошь,
и в результате на каждый чих пораждается нить. В windows тоже на каждый чих пораждать процесс дорого пораждается нить. Не путаем теплое с мягким.
>пайпами гуевые приложения, желающие меняться объектами, связывать
>бессмысленно
!? Почему ? Хоть одно обоснование приведите.
>и что каждая программка слинкована с 25 библиотеками и
>весит 15 мегабайт в памяти.
Это вообще бред.
> Пример: Есть gstreamer. Очень мощный фреймворк разнообразных
>аудио-видео кодеков-преобразователей-драйверов.
> Сейчас устройство вывода указывается в реестре. Гномовом. А узнать
>список можно, погрепав вывод консольной команды.
> А могло бы быть так:
> Для каждого приложения можно отдельно указать предпочитаемые кодеки,
>построить цепочку фильтров-преобразователей-эквалайзеров, указать
>устройство вывода, регулировать еще кучу параметров как из
>централизованной программы-апплета, так из самой программы в табе
>конфига (если она это позволяет, с галкой "использовать
>системные/выбираемые программой/свои настройки"), или из легко
>находимых текстовых конфигов. Вот это был бы pure unix way.
это не имеет никакого отношения к unix way. Это имеет к отношение к реализации ПО и использующего им свойств библиотеки. То что вы описали это photon в KDE
> Жаль, только жить в эту пору чудесную уж не прийдется
>ни мне, ни тебе.
KDE 4.0 выйдет довольно скоро.
>Сравнения с виндой производились потому, что нудна
>борьба противоположностей.
Вы хорошо знаете что такое windows но слабо что такое *nix.
>Я нигде не имел в виду, что винда заведомо лучше по каким-то
>параметрам, просто показывал, где в ее пользу отличия.
А вот как мне видится, что вы указываете только на приемущества windows и на то что она лучше ;)
