Не всосал ... ... ... Обтекаю ... :)

> Гораздо больше. Особенно тех, где настройки COM+ лежат...

Где смотреть?

То, что где-то gnome-vfs работает хреново - это мы можем поскипать, мы же архитектуру базарим, правда? И как с этим связаны утверждения про Hurd/QNX - мне не очень понятно. Там легко-дешево примаунтить новую систему? И это может сделать каждый пользователь, не только рут? И геморроя с правами при таких маунтах нет? Я уже не спрашиваю про представление сетевых ресурсов (типа Network Neighborhood) в форме файловой системы - это, конечно, там все легко, прозрачно и доступно всем пользователям?

Про RPC увидел немного умных слов - а ЧЕМ именно эти RPC лучше того, что в линухе? Особенно если эти RPC все равно, по-хорошему, нужно потом оборачивать в ОО обертку (типа той же корбы или дибаса).

Про ядра микро-немикро-ядра макоса и НТ я почти поверил (хотя Вы сами себе противоречите: "такой же отхаканный Mach, как и NT" и "Никогда не была NT микроядром"). Я же говорю о том том, что НАД ядром - то, что могут и обычно используют прикладные программеры. Все-таки униховая подсистем в макосе дает возможность с минимальными усилиями собирать униховые проги. В НТ у Вас будут проблемы - без специальных усилий (и доп. средств) Вы униховые проги не соберете. Поэтому продолжаю считать Ваше утверждение, что макос - такой же уних, как и НТ - натяжкой.

Мда. Озадачили Вы меня Вашим определением процесса. Я в тупике. Особенно с учетом того, что "процесс такого доступа не имеет" ("к общему (адресному) пространству). И как из свойств процесса "выкинуть понятие 'адрес'" - тоже загадка. Тогда грань между процессом и ядерной нитью в моем сознании совсем расплывается... Короче, продолжаю упорно не понимать. Народ (это к присутствующим), если кто-нибудь понял, что такое "пользовательский процесс" - помогите мне осознать!

>И как с этим связаны утверждения про Hurd/QNX - мне не очень понятно

И уж совсем непонятно ,как они связаны с Gnome 2.6 beta2 :)

И вот какая-то юзер-френдли поделка (Gnome) порождает споры системщиков по поводу внутренней архитектуры осей.

Линух бля ...

А Вы в курсе, что в мире все взаимосвязано?:)

Ну не надо так болезненно реагировать. Но если желаете могу развернуть.

> Особенно с учетом того, что "процесс такого доступа не имеет"

Процесс имеет доступ к своему адресному пространству (набору биндингов). К адресному пространству (набору биндингов) другого процесса он доступа не имеет.

> И как из свойств процесса "выкинуть понятие 'адрес'" - тоже загадка.

См. выше.

> Тогда грань между процессом и ядерной нитью в моем сознании совсем расплывается..

Ну обсуждали же уже - ядерные нити дороги и они в ядре.

P.S. Еще раз прошу - не обижайтесь на тупые и неудачные шутки.

Судя по данному треду даже слишком взаимосвязано ,причём такими узлами что становится страшно ... :)

>P.S. Еще раз прошу - не обижайтесь на тупые и неудачные шутки.

И не надо тут на меня намекать. Если ваши разговоры время от времени не разбавлять юмором(сатирой) то это может плохо кончится. Утянет вас блин всех в такую метафизику что вернётесь только в смерительной рубашке. А нам жертвы не нужны... :)

Да, лялих сосет. Это только говорят, что все работает независимо друг от друга, каждая програ выполняет только то, что должна, а на самом деле - вон как, чтобы гном нормально заработал нужно в едре все кардинально поменять. Лялих говешка

А кто мне может сказать почему между ярлыками на рабочем столе гнома такие большие расстояния? и как их расположить ближе?

http://www.peacefulaction.org/sayamindu/GNOME-2.6/images/default_desktop.jpg

Никак, гном - говешка!!!!!

threads & processes

в той же винде энти применяется объектно-ориентированный подход

например,
CreateXXX(...) где ХХХ название типа объекта системы, например сокет или файл или ещё что. при усложнении системы, АПИ очень удобный становится. а позикс в этом плане некрасивый, да и что зациклились все на нём ?


хороший микрокернел должен позволить не только процессам но и срэдам прозрачно распределяться в сети процессоров - то бишь я о кластерах

> хороший микрокернел должен позволить не только процессам но и срэдам прозрачно распределяться в сети процессоров - то бишь я о кластерах

И в чем тут будет выигрыш для однопроцессорной системы, не подключенной к сети?

> в той же винде энти применяется объектно-ориентированный подход

Вот по этому винда рулит а лялих сосет

Так, про процессы и адреса стало понятно. Тогда скажите - те самые пресловутые эрланговские процессы живут в одном адресном пространстве (я не имею в виду их внутреннее представление о своей жизни, я про т.зр. ОС).

Похоже, все-таки Ваш пользовательский процесс - то же самое, что моя пользовательская нить.

А разве я обижаюсь? Я просто иногда удивляюсь:))

> чтобы гном нормально заработал нужно в едре все кардинально поменять".

Это что-то новенькое. Мне казалось, дискуссия совсем в другом плане. Одни говорят, что ядро плохое и гном плохой, другие, что "усе путем". Но из ни одна из позиций не подразумевает, что при "исправлении" ядра гном "исправится". А я-так вообще утверждаю, что до тех пор пока гном стоит на позиксовых стандартах, а не на частных "усовершенствованиях" - он рулит немерянно (ну, в смысле, более-менее годится).

> хороший микрокернел должен позволить не только процессам но и срэдам прозрачно распределяться в сети процессоров - то бишь я о кластерах

А почему все в одну кучу (микроядерность и гибкая политика нитеделанья)? Что, "монолитный кернел" теперь стало ругательством на ЛОРе? Монолитный - так уж, значит, и нитки нормально распределить не могет?

Гном - кал, афтор мудак

> Тогда скажите - те самые пресловутые эрланговские процессы живут в одном адресном пространстве (я не имею в виду их внутреннее представление о своей жизни, я про т.зр. ОС).

С т.зр. ОС - естественно - естественно, они живут в одном адресном порстранстве. Но это не имеет _абсолютно_ никакого значения, так как для этих процессов нет понятия адреса.

Ведь, в конце концов, и "настоящие" процессы ОС живут в одном и том же _физическом_ адресном пространстве. Но это не имеет значения, т.к. они видят лишь линейные (виртуальные) адреса.

> Похоже, все-таки Ваш пользовательский процесс - то же самое, что моя пользовательская нить.

Ну пользовательские нити _разделяют_ общее адресное пространство (и прочие объекты ОС). Процессы же имеют собственный уникальный набор этих причиндалов.

> А я-так вообще утверждаю, что до тех пор пока гном стоит на позиксовых > стандартах, а не на частных "усовершенствованиях" - он рулит немерянно > (ну, в смысле, более-менее годится).

Когда же будет платформа (не unix), которая полностью позволит GNOME'у реализовать свои возможности, тогда он будет годиться для десктопа даже очень. Поэтому, конечно, GNOME на позиксе нужно развивать, но и про не позикс тоже задумываться.

> С т.зр. ОС - естественно - естественно, они живут в одном адресном порстранстве

> Ну пользовательские нити _разделяют_ общее адресное пространство

Во! Это разве не одно и то же (с т.зр. ОС)? Т.е. ОС создала адресное пространство (одно!) в рамках процесса (одного) - а уж живете вы там в нем или разделяете - это дело ваше. Получается (с т.зр. ОС), что все это богатство эрланга - один процесс, который (уже с т.зр. разработчика-пользователя-внутренней архитектуры) используется несколькими пользовательскими нитями. Вот и ура.

"Настоящие" процессы ОС живут в одном физическом пространстве, это да. Но мы же говорим про то, что ОС делает с этим физическим адресным пространством. И о том, что свое, независимое адресное пространство (в том смысле, в котором его понимает ОС, а не эрланг) отличает процесс от не-процесса.

> Где смотреть?

Это вопрос вида "Перечислить всех погибших на Великой Отечественной поименно". Ссылку на книжку я уже давал, а сам я не помню -- я эту муть лет 6 назад сдавал.

> То, что где-то gnome-vfs работает хреново - это мы можем поскипать, мы же архитектуру базарим, правда?

Дык работает она хреново в силу хреновой архитектуры.

> Там легко-дешево примаунтить новую систему?

RTFM: http://www.debian.org/ports/hurd/hurd-doc-translator

А вкратце:

Да (хотя там не монтирование, но фиг с ним). VFS там сидит в userspace. Поэтому ВСЕ приложения смогут использовать, скажем, ту же gnome vfs, если ее "уговорить" вести себя, как транслятор. И для этого их НЕ НУЖНО линковать с гномячими библиотеками.

> И это может сделать каждый пользователь, не только рут?

Да, если у него есть права на store и на транслируемый inode.

> И геморроя с правами при таких маунтах нет?

Грубо говоря, транслятор работает от имени пользователя, его запустившего.

> Я уже не спрашиваю про представление сетевых ресурсов (типа Network Neighborhood)

Ну, ftpfs есть :). Для того, чтоб ею пользоваться, никаких особых привилегий не надо.

> Про ядра микро-немикро-ядра макоса и НТ я почти поверил

Не надо никому верить, надо самому проверять.

http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/...

> Mach 3.0 was originally conceived as a simple, extensible, communications microkernel. It is capable of running as a stand–alone kernel, with other traditional operating-system services such as I/O, file systems, and networking stacks running as user-mode servers.

> However, in Mac OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks.

> Про RPC увидел немного умных слов - а ЧЕМ именно эти RPC лучше того, что в линухе?

Everything is file. В _буквальном_ смысле.

> Особенно если эти RPC все равно, по-хорошему, нужно потом оборачивать в ОО обертку (типа той же корбы или дибаса).

Нет, не надо! В ОО обертку надо будет завернуть POSIX read, open & friends. И все. > Все-таки униховая подсистем в макосе дает возможность с минимальными усилиями собирать униховые проги.

Почти с таким же сексом оно все собирается.

http://www.ginac.de/lists/ginac-list/msg01332.html

Насколько я понимаю, разработчики гнома не очень плачут над несовершенством позикса. И не хотят уходить с него. Да и некуда уходить-то. Если бы была реальная альтернатива - может, подумали бы (хотя сомневаюсь - все-таки униховые стандарты десятилетиями ковались, да и привыкли уже все:). Но ее, реальной, нет.

"позволит GNOME'у реализовать свои возможности". Возможности гнома рассчитаны на применение в униксовом мире. Не более и не менее. Поэтому для другой ОС, скорее всего, придется начинать все сначала:)

Короче, начните новую ОС. Сделайте к ней рулезный десктоп. И к Вам потянутся люди.

> Во! Это разве не одно и то же (с т.зр. ОС)?

Точка зрения ОС - это не та точка зрения, на которую нужно обращать внимание.

> Т.е. ОС создала адресное пространство (одно!) в рамках процесса (одного) - а уж живете вы там в нем или разделяете - это дело ваше.

Жить и разделять можно по разному.

> Получается (с т.зр. ОС), что все это богатство эрланга - один процесс, который (уже с т.зр. разработчика-пользователя-внутренней архитектуры) используется несколькими пользовательскими нитями. Вот и ура.

А с точки зрения разработчика --- имеем кучу независимых и очень дешевых процессов. Ура.

> "Настоящие" процессы ОС живут в одном физическом пространстве, это да. Но мы же говорим про то, что ОС делает с этим физическим адресным пространством. И о том, что свое, независимое адресное пространство (в том смысле, в котором его понимает ОС, а не эрланг) отличает процесс от не-процесса.

Ну так у эрланговских процессов "адресное пространство" - свое, независимое, никак не пересекающееся с "адресным пространством" других эрланговских процессов.

Народ, помнится для GNOME1 был такой апплет для панельки, который тырил из gtk-приложений верхнюю менюшку и отображал его на панели, типа как в MacOS. А нет ли подобной штуки для gnome2?

Почитал доку о трансляторах. Ну да, hurd - типичный представитель микроядерных. Только мне кажется, это все-таки расширение традиционного униксового подхода к файловым системам (и не уверен, что это позикс-совместимо - надо посмотреть их стандарты, есть ли там что-нибудь на эту тему). Все-таки исходно уних не был рассчитыван на такие "вольности". Да, выглядит это прямее gnome-vfs, однозначно (можно даже повздыхать "почему в линухе не так?"). Но, повторяю, gnome-vfs было создано для "традиционной" модели, где просто так, с бухты-барахты, примаунтить кому попало, чего попало, куда попало не дают. В той же солярке (вторая по значимости платформа для линуха, как я понял) - насколько я помню, с подмаунчиваньем все достаточно строго. И раз так - приходится изобретать gnome-vfs (хотя было бы прикольно посмотреть на порт gnome-vfs для hurd, который был бы основан на трансляторах).

> Everything is file. В _буквальном_ смысле.

Это я понял. Я не понял, чем это облегчает rpc. Я, будучи программером, не считаю очень удобным rpc через файлы (хотя, конечно, сигналы еще хуже:). Лучше всего, конечно, что-нибудь типа corba - но рассчитывать на такой сервис со стороны ядра ОС не приходится - ему все-таки место на пользовательском уровне. А на нижнем уровне - любая сущность, которую можно читать-писать - сойдет. Те же старые добрые униховые fifo сойдут, по бедности. Или вам чего-то еще надо? Работало бы быстро и надежно...

> Нет, не надо! В ОО обертку надо будет завернуть POSIX read, open & friends. И все.

Хочу CORBA! Хочу какой-нибудь ОО RPC! Не хочу читать-писать! А-а! (плача и всхлипывая)

> Почти с таким же сексом оно все собирается.

Ну, не надо аргументировать отдельным примером такой глобальный тезис. Вон я на convex пытался собрать gcc и kaffe - такие грабли были, что мама - но это же не делает convex не-унихом. Вообще, недаром нет четкого единого определения униха (буквоедам просьба не беспокоиться) - есть некое "общее представление" (у каждого, кто достаточно долгое время общался с унихом) - и, мне кажется, макос укладывается в него значительно лучше (хотя очень многие части и выпирают), чем NT.

Кстати, если смотреть формально - разница между тем, что какой-то хидер не компилируется и тем, что такого хидера НЕТ ВООБЩЕ - очень большая:) Надеюсь, Вы понимаете, о чем я.

> Точка зрения ОС - это не та точка зрения, на которую нужно обращать внимание.

Ура. Договорились ("до ручки"). Я-то как раз с т.зр. ОС и определял понятие процесса. А Вы, оказывается, с т.зр. виртуальной машины эрланга. Ну, тады для Вас вообще не должно существовать ядра:) Серьезно, нам надо было с самого начала договориться о т.зр. А то вон какой флейм развели. А ну как придется еще кто-нибудь и начнет говорить о физических процессах в процессоре...

> Я-то как раз с т.зр. ОС и определял понятие процесса.

Я не виноват:

a) Сам спор завязался с "процессы vs объекты". Где вы видели объекты с точки зрения ОС?

b) Я несколько раз приводи свое определение процесса.

с) Само определение процесса "с точки зрения ОС" достаточно искусственно.

> А Вы, оказывается, с т.зр. виртуальной машины эрланга.

Ну что в этом плохого? Эти процессы не менее реальны, чем "настоящие". Даже более - их "адресные пространства" разграничиваются во время компиляции, а не в обработчике page fault.

> А ну как придется еще кто-нибудь и начнет говорить о физических процессах в процессоре...

Именно вы и говорили о каких-то "особенно настоящих" процессах.

Интересно! А кинь линк на этот аплет

А я говорил, что Вы виноваты?:)

Соббсно, я видел тему спора "процессы ОС - объекты сами по себе - или контейнеры объектов". Кстати, на уровне ОС есть объекты - все зависит от того, что мы вкладываем в это слово.

Ваше определения я видели (и, как Вы помните, запаниковал на этом месте:). Просто оно настолько не ложилось в те рамки, к которым я привык...

А чем "искусственно" определение объекта с т.зр. ОС? (кстати, снимаю шляпу - мне иногда кажется, что большинство ЛОРовцев испытвают проблемы со словом "искусственный" - как и вообще с русской речью:)

>> А Вы, оказывается, с т.зр. виртуальной машины эрланга.

>Ну что в этом плохого?

Ничего! Просто мы говорили о разных вещах!

Ну, что такое более "настоящий" процесс - спросить можно долго и с увлечением. Особенно если начать с того, что ни одна из сущностей, о которых мы говорим, строго говоря, не существует в физическом мире:)

Я, повторяю, говорил о процессах с т.зр. ОС. Ибо только в этом контексте можно разделять ядерные и пользовательские нити. Для виртуальной машины эрланга ядра не существует. И для жабской. И, вроде, для паскалевской тоже.

ЗЫ А вообще, очень было бы узнать, с кем имею честь. Зарегистрировались бы...

немного не в тему, учитывая что вы больше о высоких материях... :))
наверное если я зароюсь в манах, то найду ответ на свой вопрос (или не найду, что тожу будет своего рода ответом), но думаю тебе не составит труда ответить. а теперь вопрос:
WM предоставляет программе некоторые ресурсы (окно, полосу прокрутки, курсоры (м.б.) например), входит ли в число таких стандартных Х-ресурсов главное меню программы? формулируя по другому - есть ли такие WM, которые показывают меню подобно mac os, одна область, которую разделяют все программы и к которой получает доступ только активная?

и даже совсем по другому - есть ли возможность написания подобного WM при отсутствии такового? это я спрашиваю только потому что никогда не писал ничего под Х, да и вообще для GUI писал что-то всего два раза за десяток лет, а не потому что мне лениво разбираться самому (скорее потому что для разбора получится очень большой кусок)

Не-а! Это вообще невозможно, посколько тулкиты делают главное меню каждый сам за себя. Может, если специально постараться, можно в рамках одного тулкита это реализовать - но WM тут не при чем.

http://carcosa.net/jason/software/obsolete/gnome-globalmenu/

Объясните мне почему Г всетаки так отстает от KDE ? Ну серьездно ... Я не трол какой нибуть и мне гном больше нравится, но когда переключаешся на KDE - кажется что у процессора MHz выросло раза в два ! Почему он так жрет процессор ? Почему GTK2 такой медленный ? Они что окуели чтоли ? Тут вроде есть люди имеющие косвенное отношение к разработке Г, обьясните почему у KDE в отновении скорости заметный прогресс от версии к версии, а у Гнома - РЕГРЕСС ? Вообще для Гнома это диагноз или еще можно поправить ? Оговорюсь что дома работаю я на K6-2 500MHz 128Mb; На работе гном работает норьмально и было бы странно если бы он умудрялся тормозить еще и там - 3MHz Xeon 512Mb ...

Offtopic:
Уважаемый svu, к сожелению тред про ядро 2.6.4 кажется закончился и
Вы в нем говорили, что смогли запустить винмодем, не могли бы Вы
рассказать как? можно по мылу gelios at rbcmail dot ru. Заранее спасибо

посмотрел. если это не Х-ресурс, то большого интереса не представляет... а жаль :-/

Неправильный изначально подход. Чтобы что-то объяснить, нужно знать, что объяснять. Приведите какую-нибудь _конкретную_ операцию, которая по Вашему мнению выполняется медленно, мы попробуем объяснить, почему это так.

По поводу GTK уже устали повторять - сам по себе GTК быстрый за исключением некоторых моментов, но их видят только программисты (например, работа с TreeView). А замедление работы для пользователя происходит в основном только когда используется _медленная_тема_. Поставьте simple или default, будет работать быстрее.

Кроме того, GNOME не ставит себе задачи скорости. Это даже в руководстве разработчика написано, что более правильная программа предпочитетльнее той, которая быстрее работает.

Тормоза GTK+ 2.0

>Кроме того, GNOME не ставит себе задачи скорости. Это даже в руководстве разработчика написано, что более правильная программа предпочитетльнее той, которая быстрее работает.

У тебя не аргументы, а говно полное! Хочешь сказать, что QT - неправильная что-ли? В своем уме-то?

>Неправильный изначально подход. Чтобы что-то объяснить, нужно знать, что объяснять. Приведите какую-нибудь _конкретную_ операцию, которая по Вашему мнению выполняется медленно, мы попробуем объяснить, почему это так.

Да рисует хотя бы медленнее, по сравнению с QT. После первого GTK+ возникает желание воскрикнуть: "Бедный GTK+! Что же эти ироды с тобой сделали!" :) Помнится тут пробегало интервью одного из разработчиков GTK+ 2.0. Он тоже говорил, что, возможно, это из-за Xrandr, возможно также, что из-за pango. Я проверял эти тулкиты (QT и GTK 2) на безумно слабой машине - PI-100. Там отчетливо видно, что QT - просто спринтер по сравнению с GTK 2! А всякие жетекашные окошки даже видно, как прорисовываются. Прямо на глазах! А вот GTK+ 1.x работает просто как ураган! Ну вот чем не измерение "на глаз"? Как грицца - видно невооруженным глазом!

А так - в хорошей скорости кода GTK+ 2.0 я не сомневаюсь. Но вот где-то есть какая-то хрень, которая мешает ему быть быстрее QT...

Сначала думал ответить приватом - но потом решил - может, еще кому понадобится. Итак,

<offtopic>

<title>Установка интеловского модема в ядре 2.6.3</title>

<body> Речь идет о модеме smartlink. Чип выглядит так:

00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 03)

Насколько я понимаю, СУЩЕСТВЕННЫМ является именно то, что он из состава ICH4.

В последних версиях драйверов alsa есть драйвер snd-intel8x0m (буква m принципиальна), который и работает с dsp этого модема (насколько я понимаю). В ядрах 2.6.х этого модуля пока нет (в той версии alsa, которая включена в ядро), нужно добавлять его туда ручками. Он там скоро будет - но пока нет. Надеюсь, в следующем релизе. Итак, я взял alsa-drivers, взял slmodem-2.9.6.tar.gz. В самом slmodem есть патч для 2.6.х - его мне пришлось руками подриховать, чтобы он накладывался на редхатовское ядро - и заменил файл intel8x0m.c на более свежий (из alsa) - иначе просто не компилилось. Построил ядро (разумеется, включив CONFIG_SND_INTEL8X0M=m). После чего заменил в modprobe.conf "alias sound-slot-0 snd-intel8x0" на "alias sound-slot-0 snd-intel8x0m". Переставил ядро, перезагрузился.

Оно поднялось, загрузилось и пошло работать. Далее, я снова пошел в slmodem и сделал "make SUPPORT_ALSA=1". Получил приложение slmodemd. Запустил его. Автоматически появилось устройство /dev/ttySL0 (точнее, /dev/pts/1) :maj 136, min 1. Это и был винмодем:)

Надеюсь, нас тут не поубивают за столь злостный офтопик.

</body>

</offtopic>

Очень верная мысль про темы. Я сам видел, как скорость меняется драматически. А темы, которые народ ставит по умолчанию, рассчитаны на быструю технику. Хотя, на моем старом проце п3-800 гном 2 работал достаточно быстро. Вообще, поиграйтесь с настройками - посмотрите, например, насколько влияет на скорость отключение алиазинга. Посмотрите, как влияет глубина цвета. Кстати, а гном какой сборки?

Насчет "првильности" программы у каждого тоже свое мнение )) Хотя этот подход конечно правильный ..
По поводу примеров операций :
1. Слушаю музыку (Rhythmbox), очень часто даже при всплывании панели (которая была hided) музыка прерывается; я уже не говорю про операции типа работы с OpenOffice / На KDE (JuK-Arts) я еще ни разу не запечатлел прерывания звука не важно что бы я не делал (И мне плевать что Arts работает с наивысшем приоритетом - это конфигурация KDE по умолчанию которая РАБОТАЕТ)
П.С. Я не вижу пути как пустить звук из Rhythmbox через esd

2. Это скорее к Наутилусу :
При таскании окна по десктопу очень заметен инерционный след от окна на экране, а значки на десктопе прорисовываются где-то через секунду (( При этом процессор работает так будто рассчитывает деструктивные процессы во вселенной. Меню наутилуса на десктопе отрывается с задержкой, и отображаеся не сразу. То-же относится и к меню на панели ...
Всего этого в KDE почти не наблюдается .

Эти пункты наиболее напрягают - складывается неприятное впечатление (мое юзеровское) от десктопа (к сожалению)..


Было бы еще интерестно узнать планируется ли что-нибуть по поводу конфигарабельности тоолбаров, например изменение размеров иконок для каждой программы в отдельности ?

Только что узнал - этот модуль уже в ядре. В БитКипере, во всяком случае. Таким образом, скоро народу останется только вторая часть балета.

И КДЕ и Гном из Debian Sid архивов ...

я с вами согласен, у меня то же наблюдается что гнома немного медленнее чем кде работает. советую вам перекомпилировать весь ГТКплюс и самого гнома.

./configure --help почитайте опции. правда наверное придётся ещё и системные библиотеки рекомпилить, чтоб результат более существенен стал.

Про ритмбокс ничего сказать не могу, не пользую. Все никак с xmms расстаться не могу, привычка к классическому винамповскому интерфейсу...

Наутилус - только что попробовал, нагрузка при таскании редко превышает 40% - в среднем 20-30. Меню, вроде, тоже достаточно быстро работает, и целиком. Главное меню притормаживает на долю секунды, это есть (кстати, Вы бы видели, как у меня винюковое меню в икспях тормозит при первом клике - и это при нахрен вырубленой "красоте"). Проц сентрино 1.6.

Про тулбары каждая прога до последнего времени разбиралась индивидуально - хотя была идея использовать единый подход (чем кончилась идея - не в курсе, успели они всех причесать или нет). Но насчет индивидуальных настроек размеров я бы не рассчитывал - уж очень это было бы не по-гномовски:) Если в гконф ключик кто-нибудь для конкретной проги положит - и то было бы удивительно. Но, я думаю, это вряд ли. А зачем?

Вообще, сравнивать по скорости с KDE не берусь - не видел последнего уже очень давно.

Да, и еще, очень странно принимать за обвинение "неправильное приложение" на счет QT - оно просто не может быть предъявлено, поскольку QT не является приложением:)

> П.С. Я не вижу пути как пустить звук из Rhythmbox через esd

у меня в дополнительных параметрах есть апплет настройки - Multimedia Properties, программа называется gstreamer-properties. Она настраивает gstreamer, чтобы он работал через esd. соответственно и rhythmbox начинает работать через esd.

Да, по поводу тенденций. Понятно, что гном 2 медленнее первого - вся эта красота с алиазингом и могутным рендерингом уникода стОит. В рамках гнома 2 я все-таки замечаю некое небольшое ускорение 2.0 - 2.2 - 2.4 - 2.6. Но не революционное - так, в отдельных областях, отдельных виджетах, понемногу.

Вообще, есть спинномозговое ощущение, что однажды гном начнут ориентировать на "продвинутый" (в смысле - с разными вкусными расширениями) x server с freedesktop.org. Но это не прямо завтра. И при этом, я надеюсь, все-таки будут стараться, чтобы жизнь на других серверах не превратилась в кошмар: опять же, Сан деньги платит, а есть еще удаленные терминалы и пр. и пр. - все-таки гном существует на деньги компаний, которые не могут "кидать" пользователей откровенно и быстро, они должны это делат медленно и ласково.

Кроме того, gstreamer все-таки медленная довольно штука, ну ничего, плата за универсальность. Могу обрадовать, и в kde, насколько я знаю, gstreamer хотят использовать.

А про торможение меню хочется задасть вопрос: у вас памяти сколько? сколько своп и какой скорости диск?