Вместо (http://www.phoronix.com/scan.php?page=article&item=xserver_1...) ожидаемого релиза X.Org 7.4 разработчики с 212-дневным опозданием выпустили (http://lists.freedesktop.org/archives/xorg/2008-June/036003....) обновление X Server 1.4.1 с исправлением 108 ошибок, накопившихся с момента выпуска X.Org 7.3 (http://xorg.freedesktop.org/wiki/Releases/7.3). Интересно, что X Server 1.4.1 был выпущен при наличии (https://bugs.freedesktop.org/show_bug.cgi?id=xorg-server-1.4.1) в трекере ошибок двух нерешенных проблем, помеченных как блокирующих релиз (проблема в XKB и утечки памяти при работе с DBUS).Семь исправленных ошибок имеют отношение к безопасности (http://secunia.com/search/?search=xorg). Изначально X Server 1.4.1 был запланирован на ноябрь прошлого года.
Выход X.Org 7.4, в составе которого будет поставляться X Server 1.5, в очередной раз отложен до исправления всех блокирующих выпуск релиза ошибок (не исправлено 36 проблем). По неофициальным данным релиз выйдет в и...URL: http://www.phoronix.com/scan.php?page=article&item=xserver_1...
Новость: https://www.opennet.ru/opennews/art.shtml?num=16420
Да нет никакого кризиса, нормально все. Кому надо соберет себе комплект Х сам, используя 7.3 и каррент.
1. Собирать Xorg я просто ненавижу из-за все тех же гнутых autotools (собирается долго + надо для каждой библиотечки (а их там немало) запускать configure, make, make install, и при этом библиотеки зависят друг от друга, так что собирать их надо в определенном порядке).
2. Все-таки надо выбрать более современный язык, например, C++ (а возможно и D). Использование Java (C#) может привести к потери быстродействия (хотя и не всегда; зато грузиться Xorg будет дольше при JIT компиляции). Код, от которого требуется наибольшая производительность (это, как правило, около 5%) можно написать и на ассемблере (что, в Java сделать сложнее + JNI не отличается особой эффективностью).
3. Наверное, архитектура Xorg уже устарела, так что, возможно, надо создать новую систему или изменить архитектуру Xorg.
>2. Все-таки надо выбрать более современный язык, например, C++Милая, да выберите и пишите. Может, поймёте по дороге, почему же для низкоуровневого системного софта как раз C и является ассемблером. И не в ём тут проблема.
>3. Наверное, архитектура Xorg уже устарела, так что, возможно, надо создать новую
>систему или изменить архитектуру Xorg.Менеджить проект надо лучше. Или у вендоров терпение лопнет, или старики опять психанут и разгонят дятлов подальше от непосредственно того, что идёт в релиз. Не пойму, как умудрились, сваливая от BSD-like модели разработки XFree86, не изучить очевидный пример и поднять а-ля LKML, а не этот бардак с кучей козлов в одном огороде.
Ядро Linux разрабатывается гораздо устойчивей из-за того, что есть структура доверия и ответственности, основанная на работоспособности результата труда конкретного человека.
А тут... распределённая безответственность: ну сломал Xv на ati, ну и хрен с ними, с пользователями. Пусть спасибо скажут, что ещё хоть что-то работает!
>Милая, да выберите и пишите. Может, поймёте по дороге, почему же
>для низкоуровневого системного софта как раз C и является ассемблером.
>И не в нём тут проблема.Дело в том, что на C обычно пишется весь проект, а на ассемблере - маленькие куски кода (к тому же код, написанный вручную на ассемблере может быть быстрее кода на всеми так любимом C). Все-таки маленький кусок на низкоуровневом языке достаточно легко "вылизать", а большую часть проекта удобнее писать на высокоуровневых языках, т. к. это позволит значительно уменьшить число багов, а на производительность практически никак не повлияет. Так что незначительное (а чаще незаметное) увеличение производительности, вызванное написанием ВСЕГО проекта на среднеуровневом C может быть "компенсировано" увеличением числа багов, уменьшением скорости разработки и сложностью добавления новых возможностей. Так что я считаю оптимальным выбор C++ (или D) с небольшими ассемблерными вставками (места, которые нуждаются в оптимизации, могут быть выявлены при помощи профилировщика). К тому же в C++ есть статические методы и функции вне классов, вызов которых должен по скорости должен быть эквивалентен вызову функции C. Иногда некоторые реализуют на C свою собственную объектную систему (наверное, самая известная - glib). Почему такие системы должны быть быстрее систем на C++ - это я не понимаю. Кстати, слышала, что в Xorg тоже реализовано что-то похожее.
>Дело в том, что на C обычно пишется весь проект, а на
>ассемблере - маленькие куски кода (к тому же код, написанный вручную
>на ассемблере может быть быстрее кода на всеми так любимом C).Не скажу, когда последний раз видел человека, который может и при этом не ленится оптимизировать код на ассемблере под современные процессоры. Они-то бывают (в моей комнате водится два), но обычно находят более разумное применение времени -- например, делать сишные вставки для кода на скриптовых языках или вытянуть ещё несколько процентов масштабируемости из наличного параллельного железа :-)
>Так что незначительное (а чаще незаметное) увеличение производительности,
>вызванное написанием ВСЕГО проекта на среднеуровневом C может быть "компенсировано"
>увеличением числа багов, уменьшением скорости разработки и сложностью добавления
>новых возможностей.Повторюсь -- не в языке в данном случае проблема, а в головах и подходе.
Насколько вообще могу судить.
>>Милая, да выберите и пишите. Может, поймёте по дороге, почему же
>>для низкоуровневого системного софта как раз C и является ассемблером.
>>И не в нём тут проблема.
>
>Дело в том, что на C обычно пишется весь проект, а на
>ассемблере - маленькие куски кода (к тому же код, написанный вручную
>на ассемблере может быть быстрее кода на всеми так любимом C).Если _хорошо_ уметь программировать на ассемблере. Иначе - далеко не факт. А уметь программировать на асме хорошо - совсем не тоже, что просто уметь программировать. Я вот умею, но не хорошо. Поэтому напишу на C.
>Все-таки маленький кусок на низкоуровневом языке достаточно легко "вылизать", а большую
>часть проекта удобнее писать на высокоуровневых языках, т. к. это позволит
>значительно уменьшить число багов, а на производительность практически никак не повлияет.Как бы это помягче сказать... Вы не правы, вот.
Во-первых, вместо багов логики (которые заметить относительно легко) начнут вылезать баги компиляторов (а вот их пойди ещё обнаружь). Или вы считаете компиляторы (особенно GCC) непогрешимыми?
C++ - ОЧЕНЬ сложный язык. На нём можно написать что угодно, но это вовсе не значит, что на нём стоит что угодно писать. Сам Страуструп говорил , что C++ реально нужен примерно 5 людям в мире (с учётом роста населения Земли и процента программистов среди оного, готов довести это число даже до 500 - суть не сильно изменится).
А D надо бы для начала самореализоваться, а уже потом на нём можно писать вещи, которые должны работать на бесчисленном числе конфигураций в самых разных условиях.
>Так что незначительное (а чаще незаметное) увеличение производительности, вызванное написанием ВСЕГО
>проекта на среднеуровневом C может быть "компенсировано" увеличением числа багов, уменьшением и
>скорости разработки и сложностью добавления новых возможностей.Опыт показывает, что багов меньше там, где, во-первых, лучше квалификация работников, а во-вторых, где используются наиболее простые схемы. C++ - это НЕ просто. И ему не место в массовом X-сервере, кроме как (допускаю) в прикладных программах, типа xeyes.
> Так что я считаю
>оптимальным выбор C++ (или D) с небольшими ассемблерными вставками (места, которые
>нуждаются в оптимизации, могут быть выявлены при помощи профилировщика).А я считаю, что Билл Гейтс должен мне кучу бабок. Уж простите за резкость, но книжки - это конечно, хорошо, но вы явно витаете в облаках.
> К тому
>же в C++ есть статические методы и функции вне классов, вызов
>которых должен по скорости должен быть эквивалентен вызову функции C.Ну и чем в этих случаях будет C++ лучше C? Повторяю, C++ - это ОЧЕНЬ мощный язык, наверное, самый мощный из существующих. Но за эту мощность приходится платить. Я люблю C++, это мой второй любимый язык после C# - но одно дело язык, а другое дело его реализация.
Это не говоря о том, что чем проще средства, тем проще ими пользоваться - меньше ошибок.
> Иногда
>некоторые реализуют на C свою собственную объектную систему (наверное, самая известная
>- glib). Почему такие системы должны быть быстрее систем на C++
>- это я не понимаю. Кстати, слышала, что в Xorg тоже
>реализовано что-то похожее.А кто вам сказал, что программирование - это гонка за скоростью?
Почему-то имеется расхожее (даже подразумеваемое) мнение, что язык, на котором писать проще, будет провоцировать написание более качественный код. Но это полная чушь. Язык, на котором писать проще, обеспечивает более быструю разработку, и только. Качество кода зависит от качества реализации языка и используемых библиотек и от качества мозгов того, кто собственно пишет код (а так же ставит задачи).
Лично я соглашусь, по крайней мере отчасти, с Михаилом: нынешняя схема организации X.org привела к бедламу, который излечить можно только сменой процесса разработки.
Как там нас учили? Низы хотят, верхи не могут, а теперь вот образуются и революционные настроения...
Да, взять хотя бы Сережку Удальтсофа. Такому же действительно проще на Джаве лабать, чем в С разбираться. Вот и имеем дырки в XKB.Это ему не ЛОРом командовать...
>>ассемблере - маленькие куски кода (к тому же код, написанный вручную
>>на ассемблере может быть быстрее кода на всеми так любимом C).
>Если _хорошо_ уметь программировать на ассемблере. Иначе - далеко не факт.Ну на самом деле сгорбить на ассемблере так как это порой делает сишный компилер еще суметь надо.Хотя если асм видеть впервые в жизни - всякое возможно.Ну тогда если на сях писать будет чайник он тоже может наворотить такого что легко оптимизируется по скорости раз в 10.Если же взять пример из реальной жизни - чисто сишный вариант XVID сливает asm-оптимизированному варианту в РАЗЫ.Просто потому что критичные к скорости куски написаны на асме и это тот случай когда лишние микросекунды запросто могут вырасти в лишние ЧАСЫ.
>уметь программировать на асме хорошо - совсем не тоже, что просто
>уметь программировать. Я вот умею, но не хорошо. Поэтому напишу на
>C.На самом деле - программировать на ассемблере большой проект глупо.Если программа в 2Кб - да, вы легко натянете любой компилер более оптимально выделяя регистры и прочая.А вот если программа будет уже 500Кб кода - вы запутаетесь в кучах переменных и нифига не сможете уже эффективно выделять регистры и в глобальном плане компилятор может обделать вас по общей оптимальности кода.Ему то пофиг сколько переменных и кода - он железный.Посему асм уместен в совсем маленьких программах где надо выжать максимум (скажем, программирование однокристаллок с крохотной RAM и Flash на борту) или пишут на сях а то и сях++ а на асме только реально критичные к скорости фрагменты (см например как написаны XVID, X264 и прочая).Тогда можно получить и скорость "почти как на асме" и общие трудозатраты лишь чуть больше чем если все вообще писано на си.
>>а на производительность практически никак не повлияет.
>Как бы это помягче сказать... Вы не правы, вот.Ишь размечтались то.Еще как повлияет.Все что связано с быстрым выводом графики очень чувствительно к лищним действиям.MS вон вообще когда делал NT 3.51 сперва сделал графику в user режиме.Вышло тормознуто и система провалилась с треском.Пришлось в кернель засунуть.Хоть и ценой стабильности.В итоге от NT4 до Висты графика живет в ядре.Большой такой кусок GDI снесен в ядро (драйвер ядра "win32k.sys").
>(а вот их пойди ещё обнаружь). Или вы считаете компиляторы (особенно
>GCC) непогрешимыми?Ну да, непогрешим он, черта с два... в любом компилере баги есть.И msvc с internal error падает, и gcc глючный код сгенерить могет особенно с -O более чем 2.Особенно меня прут предложения писать на D.А, потом, простите вы представляете себе получившийся глюкодром и что потом с ним делать?!Да, лет через ...цать когда все критичные глюки в компилере D и в коде будут отловлены оно может и будет замечательно(правда тут же накопается еще вагон глюков).Только вот к тому времени иксы пожалуй будут ничем не хуже.
>C++ - ОЧЕНЬ сложный язык. На нём можно написать что угодно, но
>это вовсе не значит, что на нём стоит что угодно писать.Написание чего-то типа иксов на сях++ приведет к распуханию системы.Работа графической подсистемы станет еще тормознее (при том что иксы никогда и не были чемпионом по скорости) и оперативки они еще больше жрать станут (а они и так скромностью не страдают - в top посмотрите если не верите).
>А D надо бы для начала самореализоваться,
А потом еще отладиться и обезглючиться.
>>Так что незначительное (а чаще незаметное) увеличение производительности,
То что относится к графической подсистеме НЕ МОЖЕТ быть незначительным и незаметным.От скорости работы этой подсистемы зависит скорость работы графики в системе.Если допустить что производительность просядет скажем всего на 20%, допустим мы смотрим HD киноху.И допустим что в идеале производительности хватает на показ всех кадров.Теперь представляете себе что 20% кадров дропнулось.Смотреть киноху станет тошновато.
Аналогично - скажем побегать в "кваку".Есть разница между 10-12 и скажем 15-20 fps.Да и compiz при тормозах как-то не очень.Более того, и интель и амд за 20% производительности - УДАВЯТСЯ.А вы предлагаете просто взять и просрать... вот только если в средне-типичной апликухе которая 99% времени ждет реакции юзера а 1% времени работает разницу на 20% юзер не особо заметит, то в случае с иксами юзер будет видеть эту разницу везде и постоянно.
>Опыт показывает, что багов меньше там, где, во-первых, лучше квалификация работников, а
>во-вторых, где используются наиболее простые схемы. C++ - это НЕ просто.По-моему, монструозность иксов и так зашкаливает за разумные пределы.Потому и баги.Быстрые и стабильные программы без багов - простые.Потому и... .А так - ну вон aMule есть.Писан на сях++.И что, там нет багов?Да их там до**я.При том гораздо более до**я чем в писаной на гольных сях transmission.
>И ему не место в массовом X-сервере, кроме как (допускаю) в
>прикладных программах, типа xeyes.+100!
>>нуждаются в оптимизации, могут быть выявлены при помощи профилировщика).
Ну допустим выявили вы их, а дальше то что?
>витаете в облаках.
Во-во.Такие фрукты уже в Сименсах меню на яве сделали.Получилось ттооррммооззнноо.И юзеров это бесило.Ну а где теперь siemens mobile вместе со своими концепциями - все мы знаем.
P.S. других идиотов делающих менюху телефона с хилым процессором на Java я не видел.>за эту мощность приходится платить. Я люблю C++, это мой второй
>любимый язык после C# - но одно дело язык, а другое
>дело его реализация.С++ и C# - хороши для программера, но вот получившийся результат если использовать не в меру и не к месту только для программера и будет хорош.А по мнению остальных - это будет поделка для маргиналов.Ну, примерно как микроядерные системы сейчас.То есть вроде идея и ничего но вот тормозные системы в которых ядро нихрена не умеет все-таки почему-то никому не нужны.
>А кто вам сказал, что программирование - это гонка за скоростью?
Ну, если не гоняться за скоростью - будете как MS с вистой пытаться найти идиотов которые бы это согласились использовать.
>Качество кода зависит от качества реализации языка и используемых библиотек и от
>качества мозгов того, кто собственно пишет код (а так же ставит
>задачи).Золотые слова.Снимаю шляпу.
>Ну на самом деле сгорбить на ассемблере так как это порой делает
>сишный компилер еще суметь надо.Хотя если асм видеть впервые в жизни
>- всякое возможно.Ну почему, современные компиляторы оптимизируют код порой очень даже неплохо, особенно ICC и MS VC. Если программа не содержит в себе циклов с (в сумме) миллионами итераций, то средней руки программисту ещё придётся постараться, чтобы дойти до того же уровня, что и компилятор. Другое дело, что, во-первых, у проги на асме не будет обвязки в виде CRT или аналога, а во-вторых, если нет таких циклов, то и время работы проги визуально практически не будет отличаться.
>Ну тогда если на сях писать будет чайник он
>тоже может наворотить такого что легко оптимизируется по скорости раз в
>10.Если же взять пример из реальной жизни - чисто сишный вариант
>XVID сливает asm-оптимизированному варианту в РАЗЫ.Просто потому что критичные к скорости
>куски написаны на асме и это тот случай когда лишние микросекунды
>запросто могут вырасти в лишние ЧАСЫ.Тут есть свои тонкости. Компиляторы не юзают SIMD (за исключением разве что замены некоторых операций с плавающей запятой командами SSE), потому что эти команды слишком завязаны на логику - компилятор ведь не знает, какие циклы будут выполняться миллионы раз, а какие - считанные единицы. Так что это как раз тот случай, когда приходится бить окна при пожаре.
>>А кто вам сказал, что программирование - это гонка за скоростью?
>
>Ну, если не гоняться за скоростью - будете как MS с вистой
>пытаться найти идиотов которые бы это согласились использовать.См. выше (да Вы и сами писали): вопросы скорости при отрисовке графики имеют совсем другую важность, чем при написании алгоритма для игры в "крестики-нолики". Но, всё же, как бы ни был быстр интерфейс, грош ему цена, коли падать будет непредсказуемо...
>Милая, да выберите и пишите. Может, поймёте по дороге, почему же
>для низкоуровневого системного софта как раз C и является ассемблером.
>И не в ём тут проблема.Уже обсуждалось. И в нем тоже. "С" не годится для масштабных проектов, тем более что в XServer сплош и рядом на "C" реализуют функционал "C++" что неспособствует ни скорости разработки ни стабильности проекта ни понимания кода сторонними разработчиками. И мифическое быстродействие С по сравнению с С++ приводить не нужно, я STL использовать никого не заставляю.
точно. обсуждалось.
и что?
> "С" не годится для масштабных проектовнда. голословное утверждение.
на него можно ответить только так:
у Вас есть отличный шанс доказать свои слова - выпустить, например, X.man.org на C++/Java/.Net/..., который будет быстрее и без глюков.а пока, например, проект KDE никак не может доказать GNOME'у целесообразность выбора С++ по сравнению с C.
И это чуть ли не единственный факт масштабного использования C++ не на прикладном уровне.p.s.:
никакого функционала C++ в XServer не реализуется.
а STL - отличная вещь.
>точно. обсуждалось.
>и что?
>> "С" не годится для масштабных проектов
>
>нда. голословное утверждение.
>на него можно ответить только так:
>у Вас есть отличный шанс доказать свои слова - выпустить, например, X.man.orgНу, как на джаве уже реалиизовано - http://www.jcraft.com/weirdx/index.html
Понятно, что proof of concept
>[оверквотинг удален]
>на C++/Java/.Net/..., который будет быстрее и без глюков.
>
>а пока, например, проект KDE никак не может доказать GNOME'у целесообразность выбора
>С++ по сравнению с C.
>И это чуть ли не единственный факт масштабного использования C++ не на
>прикладном уровне.
>
>p.s.:
>никакого функционала C++ в XServer не реализуется.
>а STL - отличная вещь.
>Ну, как на джаве уже реалиизовано - http://www.jcraft.com/weirdx/index.html
>Понятно, что proof of conceptНу короче как всегда - в теории все зашибись а на практике - никому ненужный хлам.
>Менеджить проект надо лучше. Или у вендоров терпение лопнет, или старики
>опять психанут и разгонят дятлов подальше от непосредственно того, что идёт
>в релиз. Не пойму, как умудрились, сваливая от BSD-like модели
>разработки XFree86, не изучить очевидный пример и поднять а-ля LKML, а
>не этот бардак с кучей козлов в одном огороде.
>
>Ядро Linux разрабатывается гораздо устойчивей из-за того, что есть структура доверия и
>ответственности, основанная на работоспособности результата труда конкретного человека.Есть некая существенная разница между разработкой ядра Линукс (один проект) и разработкой балканизированого Хorg (хм... > 100 проектов? поправьте), поэтому их прямое сравнение - наивненькое такое передёргивание фактов. А вот ежели "Линукс" рассматривать как собрание ядра и коллекции базовых программ, разрабатываемых разными людьми с разной скоростью, то тогда семейное сходство становится очевидным, со всеми его недостатками, включая вышеназванных козлов в огороде, и со всеми его мнимыми или реальными преимуществами.
>А тут... распределённая безответственность: ну сломал Xv на ati, ну и хрен
>с ними, с пользователями. Пусть спасибо скажут, что ещё хоть
>что-то работает!Вроде ж за то и боролись? Теперь жар творения авторов одной компоненты Xorg никак или очень слабо ограничен возможностями других, вот и лезут цветочки с ягодками.
>>Ядро Linux разрабатывается гораздо устойчивей из-за того, что есть структура доверия и
>>ответственности, основанная на работоспособности результата труда конкретного человека.
>Есть некая существенная разница между разработкой ядра Линукс (один проект) и разработкой
>балканизированого Хorg (хм... > 100 проектов? поправьте), поэтому их прямое сравнение -
>наивненькое такое передёргивание фактов.Уважаемый, а ничего, что они сами пожалели о чрезмерном дроблении? Помнится, пробегала мысля оттуда, что "lkml folks got it right", поскольку по одному дереву легче контролировать целостность и обновлённость кода при изменениях да избегать bit rot. Ссылку искать лень, простите.
Но это скорее техническая часть вопроса, которая далеко не так сильно влияет, как управление проектом. Грубо говоря, детвора в песочнице учится если и ломать, создавая -- так хоть вовремя замечать и чинить. Она-то нужна, но не бесконтрольно расфигачивающая всё подряд под свой узкий кислый вкус.
>А вот ежели "Линукс" рассматривать как собрание ядра и коллекции базовых программ
Не, я именно про ядро. (всё равно скипнутое спорно, но оставим)
>Вроде ж за то и боролись?
Ой не знаю...
>>>Ядро Linux разрабатывается гораздо устойчивей из-за того, что есть структура доверия и
>>>ответственности, основанная на работоспособности результата труда конкретного человека.
>>Есть некая существенная разница между разработкой ядра Линукс (один проект) и разработкой
>>балканизированого Хorg (хм... > 100 проектов? поправьте), поэтому их прямое сравнение -
>>наивненькое такое передёргивание фактов.
>
>Уважаемый, а ничего, что они сами пожалели о чрезмерном дроблении? Помнится,
>пробегала мысля оттуда, что "lkml folks got it right", поскольку по
>одному дереву легче контролировать целостность и обновлённость кода при изменениях да
>избегать bit rot. Ссылку искать лень, простите.Что это меняет? Они сделали именно то, что в своё время Линус рекомендовал сделать разработчикам KDE.
>Но это скорее техническая часть вопроса, которая далеко не так сильно влияет,
>как управление проектом. Грубо говоря, детвора в песочнице учится если
>и ломать, создавая -- так хоть вовремя замечать и чинить.Замечать и чинить проще в частях одного целого. Их уход от "BSD модели" от этого самого целого не оставил камня на камне. За что и расплачиваются. Нет уже проекта Xorg, на его месте образовалась аморфная масса более-менее независимых программ/библиотек в лучших традициях линуксового дистрибютостроения.
>Что это меняет? Они сделали именно то, что в своё время Линус
>рекомендовал сделать разработчикам KDE.Не знаю, почему там так рекомендовал, но Вы не находите, что некоторые рекомендации не бывают автоматически транзитивными?
>Замечать и чинить проще в частях одного целого.
Технически.
>Их уход от "BSD модели" от этого самого целого не оставил камня на камне.
Я про _организацию_ работы, а не _реализацию_ говорил насчёт ухода. А маятник попросту качнулся от того, что несколько умников сидели на коде, который тух, к тому, что толпа бесконтрольно разваливает даже те драйверы, которые уже просто работали.
Ни то, ни то разумным не является.
>За что и расплачиваются. Нет уже проекта Xorg, на его месте образовалась
>аморфная масса более-менее независимых программ/библиотек в лучших традициях
>линуксового дистрибютостроения.Ну дайте определение целостности, что ли.
Поплеваться-то в сторону организации разработки *BSD -- дело нехитрое, сами понимаете.
>>Что это меняет? Они сделали именно то, что в своё время Линус
>>рекомендовал сделать разработчикам KDE.
>
>Не знаю, почему там так рекомендовал, но Вы не находите, что некоторые
>рекомендации не бывают автоматически транзитивными?"Вы будете смеяться" - это недостаток git. Слишком плохо работает на больших репозиториях. Именно поэтому KDE-шники отказались от git и вообще DVCS. могу ссылкой кинуть, если интересно.
>>Замечать и чинить проще в частях одного целого.
>
>Технически.Так и разговор не о влиянии Пушкина на творчество художников XIX века... Меньше технических проблем (если не за счёт других вещей, канеш) - меньше геммороя всем, согласитесь.
>>Их уход от "BSD модели" от этого самого целого не оставил камня на камне.
>
>Я про _организацию_ работы, а не _реализацию_ говорил насчёт ухода. А
>маятник попросту качнулся от того, что несколько умников сидели на коде,
>который тух, к тому, что толпа бесконтрольно разваливает даже те драйверы,
>которые уже просто работали.Таки тогда поясните, плз, что такое, по-вашему, "BSD модель".
>Ни то, ни то разумным не является.
Само собой.
>>За что и расплачиваются. Нет уже проекта Xorg, на его месте образовалась
>>аморфная масса более-менее независимых программ/библиотек в лучших традициях
>>линуксового дистрибютостроения.
>
>Ну дайте определение целостности, что ли.
>
>Поплеваться-то в сторону организации разработки *BSD -- дело нехитрое, сами понимаете.Угу. А ещё зачастую и смешное - в смысле, наблюдение за этими плевками;).
>"Вы будете смеяться" - это недостаток git. Слишком плохо работает на больших
>репозиториях. Именно поэтому KDE-шники отказались от git и вообще DVCS. могу
>ссылкой кинуть, если интересно.ага.
давай.
только без KDE-шников - слишком предвзято.
>>"Вы будете смеяться" - это недостаток git. Слишком плохо работает на больших
>>репозиториях. Именно поэтому KDE-шники отказались от git и вообще DVCS. могу
>>ссылкой кинуть, если интересно.
>
>ага.
>давай.
>только без KDE-шников - слишком предвзято.Да причём тут KDE-шники, можно просто прочесть письмо Линуса и сделать выводы: http://lwn.net/Articles/246381/ . В KDE сделали свои выводы, и лично у меня нет причин считать их безосновательными. А насколько эти основания соотносятся с реальностью... Камни и в их огород можно покидать, канеш (переезд с KDE 3 на KDE 4 очень напоминает переезд с Windows XP на Windows Vista), но ведь на третью ветку, вон, тоже поначалу ругались (и я тоже), а сейчас 3.5.9 - приятно работать (не всем, конечно, но достаточно многим).
выводы сделали в троллтеч...
у меня тоже нет причин считать их безосновательными.
..
и про 3-ю ветку (сам люблю KDE и С++)
но KDE4 - нет. учу gtk. или нужен форк тройки (теоретически - возможно)
...
так вот - ПРИ ЧЁМ ЗДЕСЬ git?
вопрос об этом был...
>так вот - ПРИ ЧЁМ ЗДЕСЬ git?Угу,
$wget http://lwn.net/Articles/246381/ -O - |tr [:blank:] ['\n'] | grep git | wc
выдает 45, а git тут совсем не причём.
ну и что?
я тоже так могугде там написано:
>"Вы будете смеяться" - это недостаток git. Слишком плохо работает на больших
>репозиториях. Именно поэтому KDE-шники отказались от git и вообще DVCS. могу
>ссылкой кинуть, если интересно.зато там есть это:
But I certainly won't lie to you: importing all the history of KDE is
going to be a fairly big project, and it will require people who have good
git knowledge to set it up.недостаток знаний - корень проблем
>[оверквотинг удален]
>>ссылкой кинуть, если интересно.
>
>зато там есть это:
>But I certainly won't lie to you: importing all the history of
>KDE is
>going to be a fairly big project, and it will require people
>who have good
>git knowledge to set it up.
>
>недостаток знаний - корень проблемЕсли я отказываюсь от использования итнсрумента, которым не умею пользоваться, это ещё не значит, что дело именно в том, что я им не умею пользоваться. Если я откажусь при постройке дачи от использования башенного крана, это не значит, что дело в том, что я не умею пользоваться башенным краном. Просто он мне на хрен не сдался на шести сотках.
тяжело писано..
но это и не доказывает, что башенный кран хуже лопаты, впрочем как и наоборот...
просто все надо использовать рациональнот.е. не git плохо работает, просто для этих задач оно не нужно.
это ж совсем другой смысл.
>тяжело писано..
>но это и не доказывает, что башенный кран хуже лопаты, впрочем как
>и наоборот...
>просто все надо использовать рационально
>
>т.е. не git плохо работает, просто для этих задач оно не нужно.
>
>это ж совсем другой смысл.Угу... Просто для меня слово "недостаток" не абсолютно, всё время забываю, что это нужно уточнять во избежание неправильного понимания. Имелось в виду, конечно, "недостаток, важный для данного конкретного случая".
>>Что это меняет? Они сделали именно то, что в своё время Линус
>>рекомендовал сделать разработчикам KDE.
>
>Не знаю, почему там так рекомендовал, но Вы не находите, что некоторые
>рекомендации не бывают автоматически транзитивными?Нахожу, и даже очень. Рекомендации разломать рабочую модель разработки вдребезги и пополам лишь на том основании что она не очень хорошо поддерживается Git-ом, раздавал не я. Открытые письма подозреваемым Git-oненавистникам-уклонистам, тоже не моих рук дело.
>>Замечать и чинить проще в частях одного целого.
>
>Технически.
>Просто _проще_, без всяких "технически".
>Я про _организацию_ работы, а не _реализацию_ говорил насчёт ухода. А
>маятник попросту качнулся от того, что несколько умников сидели на коде,
>который тух, к тому, что толпа бесконтрольно разваливает даже те драйверы,
>которые уже просто работали.Реализация зачастую определяет организацию, это такая большая новость? Если для проверки совместимости изменений драйвера с остальными компонентами нужно три часа оттанцевать с бубном собирая рабочую конфигурацию из свежих версий библиотек, то добиться правильной организации работы вам удастся только при помощи взвода автоматчиков с сторожевыми вышками.
>
>Ну дайте определение целостности, что ли.Гхм, нечто разрабатываемое в составе одного дерева исходников, тривиально тестируемое как единое целое и подчиняющееся общему графику релизов?
>Поплеваться-то в сторону организации разработки *BSD -- дело нехитрое, сами понимаете.
Для вас - дело плёвое. Для меня - неочевидное, поскольку ваших видений я не разделяю.
скажи еще, что ты это делаешь вручную , все мэйки и инсталлы :D
> Код, от которого требуется наибольшая производительность (это, как правило, около 5%) можно написать и на ассемблереНа ассемблере какого процессора будем программировать: i386, IA-64, AMD-64, Sparc-32, Sparc-64, PowerPC, Alpha, ARM?
>на ассемблере какого процессора будем программировать: i386, IA-64, AMD-64, Sparc-32, Sparc-64, PowerPC, Alpha, ARM?Умный да? А ты бы в код для начала какого-нить видеодрайвера заглянул.
Вы что все так на девушку накинулись?
А на каком ассемблере написана часть ядра, угадайте?! :)
>2. Все-таки надо выбрать более современный язык, например, C++Совсем с дуба рухнули?Они и так то легкостью и производительностью не блещут а с вашими "ценными советами" они по тормозам запросто сделают Висту.Идите НАХРЕН с вашими крютыми концепциями и дельными советами - если у вас шило в ж... тоскует по высоким концепциям и вам не ехать а шашечки - берете флаг в руки и пишите СВОЙ форк а то и новый проект сколько вам влезет.Хоть на C#, и посмотрим как ваш жирный уродец будет коррелировать по производительности с хотя-бы Вистой.А в моем понимании иксы и так не больно легковесный прокт.Запустите десяток не очень легких прог, погамайте в 3D игру, посмотрите видео в HD.Анализируя при этом загрузку процессора и потребление памяти.В частности - иксами.Ну как?Вам кажется что опупительный жрач ресурсов заметный даже на машине с парой ядер и гигом оперативы - это так и надо?Ну вон MS по этой причине никак не может висту протолкнуть - бесят юзеров тормоза системы.Так что если оно станет еще тормознее и тяжелее (а с С++ и тем более нихрена не отлаженным D или совсем уж тормозным C# - станет) - юзать ЭТО будут считанные единицы маргиналов которым шашечки важнее чем ехать.
>[оверквотинг удален]
>хотя-бы Вистой.А в моем понимании иксы и так не больно легковесный
>прокт.Запустите десяток не очень легких прог, погамайте в 3D игру, посмотрите
>видео в HD.Анализируя при этом загрузку процессора и потребление памяти.В частности
>- иксами.Ну как?Вам кажется что опупительный жрач ресурсов заметный даже на
>машине с парой ядер и гигом оперативы - это так и
>надо?Ну вон MS по этой причине никак не может висту протолкнуть
>- бесят юзеров тормоза системы.Так что если оно станет еще тормознее
>и тяжелее (а с С++ и тем более нихрена не отлаженным
>D или совсем уж тормозным C# - станет) - юзать ЭТО
>будут считанные единицы маргиналов которым шашечки важнее чем ехать.Вас похоже серьезно обидели апологеты C++ / C#, что вы теперь такой злой стали. Вы как-нибудь обоснуете тормознутость C++?Да, действительно, для вызова виртуальных методов приходится переходить по указателю vtbl и проч. проч. проч., но если иметь немного мозга(я искренне верю, что он у вас есть), то можно увидеть аналогичную вещь в BSD|Linux в реализации VFS, сетевого взаимодействия. Исключения можно не использовать, благо, выбор есть, а тормозов они добавляют, да. А на шарп не гоните с открытым забралом, он хороший. Вы просто не особо понимаете, для чего он нужен ;) (Пример не очень хорошей программы - Paint.NET, пример хорошей - Bill's Process Manager)(//offtop)
Короче, пис, мир, жвачка, а про плюсы вы напишите, что вам не нравится.
>Да нет никакого кризиса, нормально все.Ага, только многие "старики", у которых код рабочий получался -- тихо исчезли из проекта. Кто в менеджмент, кто устал, наверное...
А гопота строгает код бочками -- который, однако, неживой. Такое впечатление, что пишется xorg сейчас, сидя под виндой.
к сожалению, правда.
но я не понимаю, почему некоторые думают, что если эту "гопота" будет писать на C++/D/Java/.., то и код получится "живой".
>к сожалению, правда.
>но я не понимаю, почему некоторые думают, что если эту "гопота" будет
>писать на C++/D/Java/.., то и код получится "живой".Вообще-то по-научному это называется технологичность. Возможность получать (более или менее) качественный результат при использовании неквалифицированной рабочей силы.
>>к сожалению, правда.
>>но я не понимаю, почему некоторые думают, что если эту "гопота" будет
>>писать на C++/D/Java/.., то и код получится "живой".
>Вообще-то по-научному это называется технологичность.Точно?
>Возможность получать (более или менее) качественный результат
>при использовании неквалифицированной рабочей силы.Это не про плюсы... там неквалифицированные ещё страшней режутся, чем сями :(
что именно называется (по-научному и/или нет) технологичностью?
...
а геморрой по-научному - emerods. И что?
...
x.org относится к системному программированию и "более или менее" качественный результат ИМЕННО СЕЙЧАС мы и имеем.
на прикладном уровне - так мне пох... как работает Ваша прога. Мне тока лучше.
>что именно называется (по-научному и/или нет) технологичностью?
>...
>а геморрой по-научному - emerods. И что?Беспокоит? Хотите об этом поговорить?
>...
>x.org относится к системному программированию и "более или менее" качественный результат ИМЕННО
>СЕЙЧАС мы и имеем.
>на прикладном уровне - так мне пох... как работает Ваша прога. Мне
>тока лучше.Угу. Продолжайте читать новости про утечки памяти в DBUS, хотя GC уже давно в любой кофеварке имеются.
так что такое технологичность?
а передергивать я и сам могу>Угу. Продолжайте читать новости про утечки памяти в DBUS, хотя GC уже давно в любой кофеварке имеются.
эта та хрень, которая сама знает что и когда выкинуть из памяти?
панацея для не аккуратных программистов?
не из-за него ли java считается тормозной и прожерливой?возможно таким программистам, которые выпускают релиз с утечкой памяти и поможет garbage collector, но мне кажется, что все-таки что-то другое
>[оверквотинг удален]
>
>>Угу. Продолжайте читать новости про утечки памяти в DBUS, хотя GC уже давно в любой кофеварке имеются.
>
>эта та хрень, которая сама знает что и когда выкинуть из памяти?
>
>панацея для не аккуратных программистов?
>не из-за него ли java считается тормозной и прожерливой?
>
>возможно таким программистам, которые выпускают релиз с утечкой памяти и поможет garbage
>collector, но мне кажется, что все-таки что-то другоеGC хорош для программ, которые периодически выключаются. Иначе текут сильно. Не видел и не слышал ещё ни об одной реализации GC, которая бы не подтекала (не на бумаге, а по факту). На сайте того же D, например, освещаются и другие проблемы:
"When the garbage collector does a collection pass, it must pause all running threads in order to scan their stacks and register contents for references to GC allocated objects. If an ISR (Interrupt Service Routine) thread is paused, this can break the program.
Therefore, the ISR thread should not be paused. Threads created with the std.thread functions will be paused. But threads created with C's _beginthread() or equivalent won't be, the GC won't know they exist.For this to work successfully:
* The ISR thread cannot allocate any memory using the GC. This means that the global new cannot be used. Nor can dynamic arrays be resized, nor can any elements be added to associative arrays. Any use of the D runtime library should be examined for any possibility of allocating GC memory - or better yet, the ISR should not call any D runtime library functions at all.
* The ISR cannot hold the sole reference to any GC allocated memory, otherwise the GC
may free the memory while the ISR is still using it. The solution is to have one of the paused threads hold a reference to it too, or store a reference to it in global data."Так что GC уместен в многих отраслях прикладном ПО (более того, я всеми лапами за, ибо реально экономит нервы и программиста, и зазказчика), но не там, где нужно чётко отслеживать все операции с памятью.
>GC хорош для программ, которые периодически выключаются. Иначе текут сильно. Не видел и не слышал ещё ни об одной реализации GC, которая бы не подтекала (не на бумаге, а по факту). На сайте того же D, например, освещаются и другие проблемы:вот и я о чем.
а еще GC очень плохо работает при граничных условиях.
т.е. когда проц под 100% и память вся съедена, то там такие тормоза - мама не горюй.
и, наоборот, задачка "Hello, world" на java никогда не сравница с С, ведь этот GC тоже надо в память забобахать, поднять jvm и пр., и пр.а аргумент, типа:
писали на С, получили утечку памяти, значит надо на Java перейти -
это не аргумент, а отмазка.
сколько уже дебагеров, профилировщиков, ....короче, только хороший хирург может помочь плохому танцору.
Потому что у этой "гопоты" получается писать на Яве хоть что-то рабочее, а при переходе хотя бы к С++ сразу получают утечки памяти, баги, а некоторые даже потерю производительности. Что будет если такие люди начнут кодить на С и ниже представить страшно.
Лирика конечно, лучше таких "гопников" вообще не подпускать к ответственным проектам. Но это уже к управляющим проектом.
пример, pls.
если конечно отличаем системное программирование от прикладного
..
что-то я не слышал о jvm, написанном на java
>пример, pls.
>если конечно отличаем системное программирование от прикладного
>..
>что-то я не слышал о jvm, написанном на javaБольше того, есть, например, JNode. Толку-то...
Изредка бывает надо так извращаться, не спорю. Но иногда и приходится стёкла бить в чужих квартирах - чтобы детей из пожара вытащить, например. Это же не значит, что всем всегда можно и/или нужно это делать:).
Про федору, а что с ней не так? Как это отрицательно сказалось? Можно конкретные примеры?
>Про федору, а что с ней не так? Как это отрицательно сказалось?
>Можно конкретные примеры?Сразу после выпуска 9-й Федоры не работали проприетарные дрова НВидии и АТИ
Это не с X Server-ом, а с ядром проблема. И тут намек на стабильность был.
>>Про федору, а что с ней не так? Как это отрицательно сказалось?
>>Можно конкретные примеры?
>
>Сразу после выпуска 9-й Федоры не работали проприетарные дрова НВидии и АТИ
>А для меня это хорошо, именно из за этого я понял что nv нормальный драйвер, подходящий для моих задач. А то этот хрен-пойми как написанный модуль в ядре никогда не нравился)
>Про федору, а что с ней не так? Как это отрицательно сказалось?
>Можно конкретные примеры?Федора и Стабильность ?
Ха-ха, хорошая шутка - мне понравилось :)
Расскажи ка нам от чего вдруг тебе смешно сделалось. Федора работает стабильно. У меня например. Со времен 1 и почти все ( то ли FC3 3 то ли FC4 пропустил - уже не помню). Домашний комп, домашний сервер файлопомоечный, на работе 2 года назад тоже избавился от вкоряченой чуть ли не силой провайдером FreeBSD ("поставите не бздю - не будет вам нашей поддержки!" как будто она и с бздей была, эта мифическая поддержка ...).Ну и это, как его ... Вспомнил - Линус Торвальдс тоже Федорой пользуется. Наверно ему делать нефиг как выбрать "нестабильный дистрибутив".
И по теме, на 9 X.org работает просто супер. Может мне повезло, не знаю. Видеокарта на R350, все что надо просто летает. На работе GeForce 440, тоже заметно резвее ведет себя по сравнению с Fedora 8. Надо бы попробовать самую крутизну (DRI2) со встроеными Intel, Да как то нет под рукой таких компов.
Совсем недавно нашли баг в драйвере для R500 и буквально на днях должно заработать 3D с компизом и прочими прелестями на этих ATI картах. То есть оно уже работает, но в репозиторий еще рано добавлять, мало тестировали.
А вы говорите кризис.
>А вы говорите кризис.Искренне рад за Вас. Наверное, у других высказывающихся просто чуть другие масштабы чуть других проблем, чем два хоста с половиною.
PS: про провайдура -- порадовали :)
>Расскажи ка нам от чего вдруг тебе смешно сделалось. Федора работает стабильно.
>У меня например. Со времен 1 и почти все ( то
>ли FC3 3 то ли FC4 пропустил - уже не помню).Согласен. Сам года 2-3 на федоре первой сидел(с редхата9 перешел). Никаких проблема. Сервера правда не фре и дома щас деском тоже фря, но это не принципиально. Федорой был доволен, работала нормально. И с видюхой встроенной интел и с ЖеФорс 5700. Так что про федору народ зря. Кстате федора4 показалась гораздо глючнее(тормоза сильные были) чем первая.
самый лучший дистр.
как бы я ни хотел deb, но...
...
пока redhat в fedora задают тон.
а все остальные - подпевают.
Кризис на лицо, не нужно отрицать то, что есть, факт остаётся фактом, даже, если не признают некоторые...*XORG*
А что вы собственно хотите от реализации x-windows как некоего стандарта?
>А что вы собственно хотите от реализации x-windows как некоего стандарта?Что такое x-windows?
прям как open solaris
По мне, так важнее чтоб фиксились ошибки и писались дрова, а всякие фичи -- второстепенны
Если бы не фичи, то до сих пор бы приходилось на каждый чи и пук в конфиг лезть, а сейчас и моник можно второй к ноуто завести, через xrandr настроить (если видюха нормальная), да и клавиатура/мыши/видео само определяется не говоря про разрешение. А кризис да, судя по всему есть.
>Если бы не фичи, то до сих пор бы приходилось на каждый
>чи и пук в конфиг лезть, а сейчас и моник можно
>второй к ноуто завести, через xrandr настроить (если видюха нормальная), да
>и клавиатура/мыши/видео само определяется не говоря про разрешение.Вот не надо только про разрешение :(
У меня на домашнем мониторе оно пытается встать в 1920x1200 (@75, кажется) вместо нормальных для него 1600x1200@93.
Ума не приложу -- каким местом надо было думать, чтоб сломать забирание разрешений из xorg.conf и кому мешало, чтоб работало и так, и так.
Если бы работало и с указанием в xorg.conf, и на автомате (при отсутствии строчки, секции или вообще конфига) -- да, была бы фича. А так багофича. Для меня вот -- чистая бага, с учётом того, что переключение по Ctrl-Alt-+/- тоже сломалось.
Да... а я устал с мышью бороться. После перехода на xorg 7.3 на A4 Tech скролинг перестал работать, что тока не делал...Будем надеяться на лучшее...
эмуляцию 3 кнопки убери
>[оверквотинг удален]
>вместо нормальных для него 1600x1200@93.
>
>Ума не приложу -- каким местом надо было думать, чтоб сломать забирание
>разрешений из xorg.conf и кому мешало, чтоб работало и так, и
>так.
>
>Если бы работало и с указанием в xorg.conf, и на автомате (при
>отсутствии строчки, секции или вообще конфига) -- да, была бы фича.
> А так багофича. Для меня вот -- чистая бага,
>с учётом того, что переключение по Ctrl-Alt-+/- тоже сломалось.use xfce-setting-show,Luke
It is less hardcore but works.
>>с учётом того, что переключение по Ctrl-Alt-+/- тоже сломалось.
>use xfce-setting-show,LukeI can even use xrandr(1) man, but that's not a replacement for age-old (and robust!) hotkeys.
>It is less hardcore but works.
BTW it's wmaker over here, no xfce around.
>По мне, так важнее чтоб фиксились ошибки и писались дрова, а всякие
>фичи -- второстепенныКстати, вам тогда лучше вообше на XFree86 вернуться. Mesa/Dri/Freetype - это сторонние разработки, так что дрова пишутся независимо. А в XFree86 в лавке один Marc La France остался, который время от времени ошибки фиксит и бывает даже кое-что мержит из xorg.
кризис отличается от медленной разработки
А когда вы последний раз жали кнопку Donations? Что тогда обижаться.
Если есть сомнения в квалификации команды xorg, то есть ещё xfree86.
Конкуренция, блин...
Единственной альтернативой X является встроенная поддержка графики в ядре, но это уже слишком, тем более что это противоречит великолепной идее клиент-сервер.
>Из-за задержки выпуска X.Org 7.4 разработчики Fedora Linux были вынуждены включить в состав дистрибутива ранний пре-релиз X Server 1.5, что отрицательно отразилось на стабильности продукта.вот интересно, кто их вынуждал? че нельзя было на стабильной ветке релиз выпустить? имхо в федореном горе надо ж быть в переди планеты всей, а остабильности особо никто и не думает
> вот интересно, кто их вынуждал? че нельзя было на стабильной ветке релиз выпустить? имхо в федореном горе надо ж быть в переди планеты всей, а остабильности особо никто и не думаетАнегдот:
Приходит мужик в аптеку и говорит:
- я у вас свечи от гемороя купил, а они не помогают. Уже три штуки съел.
Аптекарь:
- вы их едите?!!!
Мужик (с сарказмом):
- нет, я их в опу засовываю!Федора ориентирована на bleeding edge. Если тебе нужны вчерашние версии софта, используй вчерашнюю Федору. Она же работает, не правда ли?
>Федора ориентирована на bleeding edge. Если тебе нужны вчерашние версии софта,
>используй вчерашнюю Федору. Она же работает, не правда ли?Режется уже тухлым bleeding edge даже через двухсотметровый слой апдейтов? ;-)
ваще не понимаю тех кто федорино горе юзает, сидеть на полуглючном совте да еще и сервера подымать. не ну фтп сервер можно конечно поднять, но что посерьезнее надо дебиан юзать.
>ваще не понимаю тех кто федорино горе юзает, сидеть на полуглючном совте
>да еще и сервера подымать. не ну фтп сервер можно конечно
>поднять, но что посерьезнее надо дебиан юзать.А что в нем глюченное? Давай конкретнее. Для серверов я бы правда тоже не стал использовать, но это к делу не относиться.
Это вопрос и ко всем остальным, кому федора не угодила.
Да, может быть федору и не используют на серверах, но чтобы всключить в релиз глючную недоделанную бету, до этого не всякий додумается. В конце концов, могли бы и старую версию запихнуть.
Самый лучший вариант - использование постоянно обновляющегося дистрибутива, например Арча. У них критические пакеты тестируются около недели до попадания в основную ветку. А всякие кандидаты и беты отправляются с unstable.
>Да, может быть федору и не используют на серверах, но чтобы всключить
>в релиз глючную недоделанную бету, до этого не всякий додумается. В
>конце концов, могли бы и старую версию запихнуть.
>Самый лучший вариант - использование постоянно обновляющегося дистрибутива, например Арча. У них
>критические пакеты тестируются около недели до попадания в основную ветку. А
>всякие кандидаты и беты отправляются с unstable.Не будь таким наивным, в Arch мало что отправляется в unstable. И внимательно посмотри какой в нем XServer, такой же как и в федоре.
Если бы эту версию объявили не пререлизной, а релизной, все похоже были бы счастливы.
$ pacman -Qs xorg-server
local/xorg-server 1.4.0.90-13 (xorg)
X.Org X servers
Это конечно моё скромное мнение, но на мой взгляд всё что делает freedesktop.org - гавно. Скажите мне, нах X'ам DBUS, а HAL? Я не удивлюсь если они скоро от гнома зависеть будут. Короче повелся весь мир на это попсовое г..., а теперь удивляются.
>Это конечно моё скромное мнение, но на мой взгляд всё что делает
>freedesktop.org - гавно. Скажите мне, нах X'ам DBUS, а HAL? Я
>не удивлюсь если они скоро от гнома зависеть будут. Короче повелся
>весь мир на это попсовое г..., а теперь удивляются.Правильно, всем молчать и юзать венду. А то, ишь, расшумелись - то им не нравится, это...
Посмотрим через сколько времени обратно запроситесь...
>Скажите мне, нах X'ам DBUS, а HAL?А они иксам и не нужны. Реализация D-BUS у них, если не ошибаюсь, собственная, от libdbus Xorg не зависит. И HAL тут опционален: Xorg сам не стучиться к HAL за информацией об оборудовании, он вообще не имеет представления о существовании HAL. Но если ты хочешь использовать hotplug в X'ах, то тебе нужно каким-то способом передавать X'ам сообщения о подключении/отключении через D-BUS. Примочка к HAL, делающая это, - только один из возможных вариантов. Хотя и самый очевидный.
почти так...
а еще гребаный compiz...