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

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

И, абстрагируясь от личных вкусов, война десктопов не ведется на десктопах сисадминов и программеров, она ведется на десктопах клерков. И если гном хочет ее вести, эту войну - он должен использовать подходящее вооружение. Что он и делает.

> Готов спорить, что меньше, чем у gconf (хотя, повторюсь, в gconf это просто детали реализации).

Несколько сотен, AFAIK.

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

Для registry он есть, для gconf (пока?) нету.

> Важнее, сможете ли Вы починить файл реестра текстовым редактором.

Если я не знаю смысла ключей, то я не починю ни gconf, ни registry. А "текстовые" файлы, это хорошо, конечно, но на скорость работы они влияют не в лучшую сторону. > Еще гном хорош свое политикой интеграции десктопа

<IMHO>

Для того, чтоб приложения умели друг с другом работать, нужно пинать kernel hackers на предмет _нормального_ [IR]PC. Для того, чтобы GUI более-менее прилично выглядел (но при этом таки был настраиваемым), нужно пинать XFree86 hackers на предмет server-side widgets.

А всякие bonobo, gnome-vfs -- это грязные хаки (как и KPart/Kioslave). </IMHO>

> И, абстрагируясь от личных вкусов, война десктопов не ведется на десктопах сисадминов и программеров, она ведется на десктопах клерков.

1) UNIX'-ам там не место. Точка.

2) Если уж из NT получилась m$ Windoze, то что получится из Linux, и подумать страшно...

Re[5]: Windows registry vs gconf

Нормальная, универсальная система обмена сообщениями уже существует и активно развивается - это D-BUS. И поддерживать ее будут и KDE, и GNOME. И работать она будет в userspace - нечего все подряд в ядро пихать.

По поводу server-side widgets - тебе захотелось танцев с бубном как в винде всякий раз, когда надо чуть-чуть изменить дефолтный интерфейс? Жалко, что в Qt и GTK+ все рисуется самим тулкитом, все виджеты организованы в иерархию наследования и можно перекрыть пару методов, а не переписывать весь look&feel заново? А в винде все GUI'шные ОО-библиотеки висят на ее родной системе контролов, как на корове седло. Точно так же будет и с server-side widgets, разорви их шайтан.

Да, d-bus это просто сказка. Это - надежда свободного десктопа. И рулез форево. Наконец-то будет нормально реализован клипборд между всеми с любыми данными, нотификация, и т.п. И все это унифицировано. Freedesktop.org - forver and the best!

Несколько сотен файлов в винюковом реестре??? Для меня это действительно новость. Вас не затруднит указать каталог, где лежит это все богатство?

Альтернативный бекенд реестра - это что? Да, для гконфа, кстати, есть альтернативный бекенд на Berkley DB (http://perkypants.org/projects/gnome-2.0-interviews/gconf/).

Если Вы не знаете смысла ключей - Вы не почините, это правда. Но ключи, как было уже указано, в большинстве случаев вполне читаемы и понятны. Разумеется, это зависит от авторов приложения. Но в реестре проблема двойная - сначала докопаться до ключей и значений (в двоичном формате), потом понять смысл ключей. Ладно, это все мелочи реализации одного из бекендов гконфа (в конце концов, двоичные файлы Berkley DB я тоже прочесть в редакторе не смогу).

При чем тут kernel hackers и нормальный rpc? Гном должен работать не только на линухе. И поэтому требовать от ядра чего-то особого не может - на других унихах этих супер-сервисов просто не окажется. Сервер-сайд виджетс - тоже утопия в современных иксах - потому как кроме xfree есть другие серверы (уже даже на писюках идет процесс размножения серверов - особенно в связи с новой лицензией). А еще есть удаленный режим работы - и там вообще ничего предсказать нельзя, там вообще какой-нибудь винюковый икс-сервер может быть.

Гном-вфс - это действительно, в некотором смысле, хак. Вокруг тяжеловесной семантики униксовой файловой системы. Но хак работающий и решающий свои задачи.

Короче, гному приходится жить в реальном мире сегодняшнего униха - и, ей-богу, он вполне неплохо справляется.

Почему униксам не место на десктопе - мне совсем не понятно. Особенно, когда смотрю на маки. И то, что может получиться на линухе, гном вполне неплохо демонстрирует. Справляется. Если бы еще побОльше стандартов выросло из фридесктоп.орг - было бы просто замечательно.

> Нормальная, универсальная система обмена сообщениями уже существует и активно развивается - это D-BUS. И поддерживать ее будут и KDE, и GNOME. И работать она будет в userspace - нечего все подряд в ядро пихать.

IPC и RPC при любом раскладе просто _обязано_ быть частью ядра. Собственно, это и есть то, чем ядро должно заниматься. А вот всякую фигню вроде FS, TCP/IP (и еще много чего) туда и впрямь незачем пихать (все, хватит разводить пропаганду микроядер:)).

> По поводу server-side widgets - тебе захотелось танцев с бубном как в винде всякий раз, когда надо чуть-чуть изменить дефолтный интерфейс?

А не надо его менять.

> Жалко, что в Qt и GTK+ все рисуется самим тулкитом

1) Это и есть основная причина пресловутой тормознутости X'-ов. И вроде как есть сетевая прозрачность, но без как минимум 10Mbit'-ной сети ее не видать, как своих ушей... 2) А что, кроме Qt и GTK больше никаких toolkit'-ов нет? И для каждого писать тысячу раз одно и то же?

Кроме того, это вызывает еще кучу проблем -- начиная от security заканчивая просто мелкими, но неприятными глюками, когда widgets перемешиваются в кучу (напр., на кнопках шрифты большие, или менюшка по размеру больше окна :)).

>А вот всякую фигню вроде FS, TCP/IP (и еще много чего) туда и впрямь
>незачем пихать (все, хватит разводить пропаганду микроядер:)).

что значит хватит ? интеллект всегда побеждает, поэтому и линукс станет микроядром (только вот не появится ли линуксу более достойный конкурент то же из рядов GNU)?

>Это и есть основная причина пресловутой тормознутости X'-ов. И вроде как
> есть сетевая прозрачность, но без как минимум 10Mbit'-ной сети ее не
>видать, как своих ушей...

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

> Несколько сотен файлов в винюковом реестре??? Для меня это действительно новость.

Поздравляю :) Новости о NT 3.5 достигли и Вас :) > Вас не затруднит указать каталог, где лежит это все богатство?

Разбросано по всей ФС.

HKEY_LOCAL_MACHINE\SYSTEM \Winnt\System32\Config\System

HKEY_LOCAL_MACHINE\SAM \Winnt\System32\Config\Sam

HKEY_LOCAL_MACHINE\SOFTWARE \Winnt\System32\Config\Software

HKEY_USERS\<SID or username> \Documents and Settings\<username>\Ntuser.dat

И еще дофигищи мест, где оно все валяется.

> Гном должен работать не только на линухе. И поэтому требовать от ядра чего-то особого не может - на других унихах этих супер-сервисов просто не окажется.

Более убогого RPC, чем у Linux, еще поискать надо... :(

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

GTK есть и под DirectFB...

> - потому как кроме xfree есть другие серверы (уже даже на писюках идет процесс размножения серверов - особенно в связи с новой лицензией).

Не надо плодить сущности сверх меры.

> Гном-вфс - это действительно, в некотором смысле, хак.

Это в прямом смысле хак. Грязный хак.

> Вокруг тяжеловесной семантики униксовой файловой системы.

Вокруг убогой VFS монолитного ядра.

> Почему униксам не место на десктопе - мне совсем не понятно.

Если сделать, чтоб системой могли пользоваться идиоты, то только они ею и будут пользоваться. UNIX изначально рассчитан на грамотного пользователя.

> Особенно, когда смотрю на маки.

Там от UNIX остались рожки да ножки. Так можно и NT с Interix'-ом UNIX'-ом обозвать...

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

Благородный дон когда нибудь видел QNX?

слизали всё с Mach/Hurd

имхо надо Hurd в массы помогать двигать

я позавчера пробовал ставил QNX - нахуй бы, у него лицензия коммерческая. обрезанный шелл, короче просто хз что

Да, linux -- монолитная система, и я согласен, что микроядро лучше.
Если бы у вашего сообщения не был такой спорный заголовок, я бы, вероятно,
согласился с большинством ваших высказываний. С теоретической (и
эстетической) точки зрения linux проигрывает. Если бы ядро GNU было готово
прошлой весной, я бы и не взялся за свою разработку: беда в том, что оно не
было готово тогда и не готово до сих пор. Linux выигрывает прежде всего
потому, что она уже готова. (Торавльдс в письме Таненбауму)

а GNU Hurd уже давным давно существует. и Darvin ещё есть и Mac OS X

Да пусть пользуются, жалко что ли?

А чего тебе в модулях не хватает? Разве что менять само ядро на лету. Дык думается, что скоро придумают как.

самая главная фича микрокернела --- распределённость и стабильность.

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

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

>Слушай, сказочник, в QT используется тот же XFT что и в GTK 


тебе скриншот прислать, типа да?...
я говорю в QT все ок в GTK все коряво (при условии что выключен AA).

> Да пусть пользуются, жалко что ли?

Dselect'у, по-видимому, не нравится, что куча народу пользуется Linux'ом на десктопе, решая свои задачи, и при этом зарабатывает сильно больше него.

чего не хватает

> А чего тебе в модулях не хватает?

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

Модули делают, что хотят. И частенько роняют ядро. :(

> Дык думается, что скоро придумают как.

То-то крякеры будут рады :(

не жалко, но...

уже появились патчи, уродующие ядро для "ускорения" X'-ов, KDE и прочей лабуды. Не приведи Великие Боги, чтобы эту муть включили в vanilla kernel...

> > Только призываю еще раз вспомнить, на кого ориентируется гном.

> Дык я _ИМЕННО_ за это не него и ругаюсь, если Вы еще не поняли.

Дык получается ты хернёй занимаешся :) Потому что тебе нечем занятся. Как говорят правильные хакеры "что-бы решить интересную проблему найди проблему которая тебя интересует"

Re[5]: Windows registry vs gconf

> А чего тебе в модулях не хватает? Разве что менять само ядро на лету.

где то было описание как это делать

> я говорю в QT все ок в GTK все коряво (при условии что выключен AA)

Иногда у Qt и GTK раходится мнение по поводу размера (точнее, DPI) твоего монитора. Попробуй отключить (а если выключен - включить =)) DCC в XF86Config. В крайнем случае, можно попробовать задать размеры ручками.

Только не надо спрашивать, как... =) man xf86config, там все есть

>"Чем КДЕ лучше? - Лучше, чем гном":) мне в гноме катастрофически не хватает одной фещи, которой так же не хватает в винде, но зато оена есть в кде и флукс (под дкоторм и сижу)

- это кнопка ПОВЕРХ ВСЕХ ОКОН или как во флуксе управление слоями (млжет конесно оно и в гноме есть но мне на глаза не попадалось )

kefiiir

чего вы так паритесь насчёт кутэ и гнома ?

ГНОМ РУЛИТ ИЗ=ЗА GPL

кутэ продукт КОММЕРЧЕСКИЙ, но так же как и опера кампания имеет
бесплатный ОБРЕЗАНЫЙ вариант с особой лицензией Q Public License. именно поэтому редхат например не считает кутэ основной средой, а мозилла строится на ГТК и вообще писать приложения только для кутэ-кде плохой стиль, если вы решили делать на GPL лицензии свой софт.


очень часто чайники не подумав толком начинают писать на кутэ и делают совсем непереносимый код сильно привязаный к кутэ, но как время показывает, постепенно приходят к ГТК.


больше об этом поищите на оупенсорс орге.

> HIG, если и скопирован, то с маковских стандартов, а не с винюковых.

Из CDE, за основу был взят "Motif and CDE 2.1 Style Guide".

Gnome = LGPL
KDE = GPL
=> KDE - true free soft, for free people

> или как во флуксе управление слоями (млжет конесно оно и в гноме есть но мне на глаза не попадалось )

Это зависит от используемого WM. Посмотрите на http://sawmill.sourceforge.net

Ухх! Вы меня успокоили! Все-таки, не сотни - в пределах пары десятков. Да, про system32/config - это была новость, про ntuser.dat уже я знал. Только в system32/config файлов все-таки 20, при том, что там еще Event Log лежит. Так что вопрос о сотнях файлов остается открытым:) Прошу указать еще немного из той "дофигищи мест".

Про RPC - это интересно. Расскажите, чем доступные в линухе способы rpc хуже других. Вроде, все позиксовые стандартные методы работают. А чего Вам еще надо? Опять же, заточки "под конкретную систему" - это всегда плохо пахнет, код плодится, его как-то поддерживать нужно. А CORBA - это, все-таки, стандарт.

GTK есть под DirectFB. И даже под винюки. Но как основное направление развития эти среды никто не рассматривает - и это правильно. И GNOME (не GTK!) никто пока не собирался портировать с иксов на другие платформы.

Насчет расплодившихся иксов - согласен. Меня самого это очень раздражает (потому как каждая реализация добавляет свою кривизну в расширение XKB:). Но ведь это же неправильно - иметь единственную реализацию чего-нибудь. Linux is about choice:) Если серьезно - мы имеем то, что имеем. И единственный способ с этим сосуществовать - бороться за введение стандартов - а совсем не отстреливать тех, кто форкает xfree.

Я все-таки настаиваю на том, что gnome-vfs - хак (ну, грязный или нет - это вопрос личной оценки:) именно вокруг униксовой семантики файловой системы. Монолитность ядра тут не при чем. gnome-vfs сделан так, чтобы работать на любом унихе, поддерживающем тяжелую позиксовую семантику файловой системы - поэтому никакие прогрессивные изменения в линуксовом ядре не избавят от необходимости существования gnome-vfs. Вот если бы гном строили только для какой-нибудь plan9...

Unix изначально рассчитан на грамотоного пользователя, это правда. Но никому не запрещено выдать form-based интерфейс на каком-нибудь motif, в иксах, бухгалтеру - и он даже не будет догадываться, что где-то там есть сильно могутный шелл, какое-то там ядро и прочие мудрые вещи. Современный десктоп - тоже спокойно способен запрятать всю мошь униха под коврик (причем - не "с концами", а так, чтобы ее достать оттуда было можно, при желании - это важно, иначе я не согласен:).

Про то, что NT можно назвать униксом, Вы все-таки передергиваете. Все-таки макос - это микро-ядро с биэсдишной (униховой!) надстройкой, а дальше - "видимость" (собственная система конфигурации,аква и пр.). NT же, будучи изначально микроядром, так и не обзавелось приличной позиксовой системой. Зато подсистема win32 корни в ядро пустила.

:) Да, я про это читал. Буквы оттуда. Только посмотрев на то, какие люди там заправляют (например, на отцов почившего Eazel) - и куда идет процесс, я скорее ассоциирую эту культуру с маком.

Мне кажется, спор о gconf беспредметен. Это действительно нормальная система конфигурирования, по-крайней мере в интерфейсе, это признают все. Под интерфейсом может быть все, что угодно.

Из недостатков, которые лично мне не нравятся - нет возможности сохранения данных. Очень часто нужно запоминать не опции настройки, а текущее состояние программы перед выходом, чтобы при старте восстановить его. То есть, скорее всего, кроме системы конфигурирования, нужна система сохранения сеансов. Может быть, конечно, эта проблема может быть решена возможностью сохранения образов процессов или сериализацией объектов.

Но вот что хочется отметить, так это то, что unix/posix интерфейс стал действительно тяготить программирование на десктопе. Ну не нужны для приложения на десктопе posix threads и так далее. С этой точки зрения, объектно-ориентированные интерфейсы GNOME гораздо привлекательнее. А вот объекты, которые реализуют интерфейс Runnable довольно полезны. Поэтому когда речь заходит о поддержке всех остальных Unix, я не думаю, что это нужно. Тем более что и они уже ушли вперед своим путем, например сановская десятка.

Здесь можно отметить и проблему DBUS, дело в том, что это все-таки средство межпроцессного взаимодействия, а не межобъектного. То есть, в некотором смысле это шаг назад. Вызван он многими причинами. Многие программисты не принимают CORBA в GNOME только потому, что обслуживание такой инфраструктуры требует написания большого кода на C, во вторых, из-за неразвитости соответствующей инфраструктуры. Все-таки CORBA в GNOME один человек только занимается по-существу. в третих, тут есть и политические причины (RedHat vs Ximian). Все это очень грустно.

Так что хочется призвать программистов - умейте использовать разные идеологии, и в каждой из них стремитесь к целостности.

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

программистов спрос призывает и ясные цели. позиксовые функции ещё при компилировании можно автоматом заменить некоторые. кстати, NT полностью поддерживает позикс ?

> Мне кажется, спор о gconf беспредметен.

Согласен. Я просто хотел узнать побольше о реестре и его сотнях файлов:)

Сериализация объектов - действительно потенциально сильная вестч (знаю по жабе). Но, увы, пока гконф к ней не готов. Вроде, и реестр тоже. Т.е. понятно, запихать на уровне текста можно все, что угодно - но прямой поддержки нет (или я опять про реестр чего-то не знаю?:)

> когда речь заходит о поддержке всех остальных Unix, я не думаю, что это нужно

???? Вы это как себе представляете? Сан вкладывает деньги в гном - а солярку мы поддерживать не будем. И, чтобы у HP случайно не зародилась мысль о поддержке гнома - ему мы тоже покажем фигу? Этак мы далеко уйдем... И куда ушла сановская десятка - можно пояснить мысль, я как-то не очень понял?

>программисты не принимают CORBA в GNOME ... потому, что ... требует написания большого кода на C

Извините, но мне сложно представить более-менее полную ОО модель взаимодействия, для которой код на С был бы коротким (любителям С++ просьба не беспокоиться). Но реально CORBA в GNOME мало кому нужна в чистом виде, для использования напрямую (хотя я одно время пользовал - вполне юзабельно!). Нужен бонобо (тоже подарочек - и вот тут-то действительно кода нужно понаписать немало:) А вот то, что всем этим занимается только Майкл Микс - возможно, проблема. У него головной боли и с ООо хватает.

Последняя мысль, безусловно, правильная, хотя я и не понял, как она вытекает из всего вышесказанного:)

Я читал. Весьма нестабильная и опасная штука.

Бесплатный обрезанный вариант - qt 2.3 по винды.

> программистов спрос призывает и ясные цели. позиксовые функции ещё при компилировании можно автоматом заменить некоторые. кстати, NT полностью поддерживает позикс ?

при установленном SFU да. http://www.microsoft.com/windows/sfu/default.asp

>нтеллект всегда побеждает, поэтому и линукс станет микроядром

>(только вот не появится ли линуксу более достойный конкурент то же

>из рядов GNU)

Уже появился - ФОСФОР называется -

http://beos.spb.ru/program/84/PhOSb5.iso.zip

------------- Не забудь cue-файл закачать для Nero.

> - это кнопка ПОВЕРХ ВСЕХ ОКОН или как во флуксе управление слоями (млжет конесно оно и в гноме есть но мне на глаза не попадалось )

В 2.6 она есть.

Представим себе операционную систему без процессов - их заменяют объекты. Естественно, это не операционная система для серверов, и, тем более, не встраиваемая система. Преимущества такого подхода, кроме единой идеологии и сетевой распределенности, хотя бы в возможости той-же сериализации. Как раз проблемы возникают в Bonobo именно на почве процессов - трудно увязать объект, выполняющий методы, с процессом, в котором этот объект реализован. А что будет, когда в процессе реализовано несколько объектов? Возникают проблемы синхронизации, и почему-то в этом укоряют Bonobo, пытаясь заменить его на DBUS (он ведь ориентирован на процессы), но ведь это недостаток самой системы.

Если будет пример, SUN внесет необходимые изменения за год, и выпустит совместимую с такой операционную систему. А вот изменить что-то в Linux, так это, наверное, вообще невозможно. Наоборот, появятся куча противников, которые как раз будет протестовать против этих изменений, именно потому, что якобы нужно поддерживать POSIX, хотя сам по себе POSIX не нужен.

Более того, сановская десятка это прежде всего полноценная платформа для Javа приложений. Продукты Microsoft - полноценная платформа для .NET приложений. А Linux что поддерживает - POSIX и С?

Про то, что писать с ОО подходом и распределенно на С сложно, так кто же с этим спорит. Я не сторонник C++, я даже считаю, что в glib создана более удобная объектная система - например, есть сообщения и т.д. Но и она требует много кода. Я с завистью вспоминаю jav'у, когда мне приходится реализовывать очередной glib-овский класс. Но ведь не все сошлось на С.

Миша Микс действительно наш человек, но дел у него просто завались. Я не понимаю, неужели в ximian не нашлось другого человека для работы с OpenOffic'ом? Потому что работа над Bonobo и тем более над bonoboui встала совсем. Тут вообще интересный момент - с этим релизом многие проекты "встали". Почти нет изменений во всех библиотеках gnome (кроме gtk, gnome-vfs). Некоторые майнтейнеры вообще потерялись, как у libglade и vte. Все это заставляет задуматься.

У процесса - две точки соприкосновения с окружающим миром - ввод и вывод. Они присутствуют у всех процессов.

У "объектов" - месиво из методов, уникальных для каждого объекта.

Очевидно, что декомпозиция в множество процессов - более полное и красивое решение задачи, чем порождение кучи кривых объектов. Зачем тянуть ОС в темное прошлое?

gentoo - кал

> gentoo - кал

Нет, здесь кал - Gnome, Gentoo кал в соседнем треде

Почему ОО ОС не для серверов и не встраиваемая - мне, соббсно, не совсем понятно (ну, если не брать в расчет ресурсоемкость:). Уж для серверов-то сам Бог велел (точнее, Sun & J2EE:). В остальном, про процессы и объекты согласен. Но от процессов не убежать - это уних, джентльмены. Просто надо научить объекты мирно сосуществовать в рамках одного процесса:)

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

"сановская десятка это прежде всего полноценная платформа для Javа приложений" - в чем это выражено, на архитектуром уровне, на уровне системых сервисов? И чего не хватает Линуху для того, чтобы стать жабской платформой? Это не спор, это вопрос (я знаю только про проблемы с тредами и стеком - если их еще не порешили).

Миша Микс - ну, я бы не сказал, что именно "наш человек". Отпинываться от улучшений в бонобо он горазд. Хотя, возможно, именно в силу занятости. Но ведь "взялся за гуж..." Не говоря уж о том, что ему сам Бог велел свяать мост из UNO в бонобо - так ведь некогда ему... Короче, пора ему клонироваться...

Процессы дороги (хотя в унихе и дешевле, чем в NT). Нынче в гноме даже несколько экземпляров одного и того же апплета ЖИВУТ в ОДНОМ процессе!

> Процессы дороги

В NT, Solaris и т.д. В общем везде, где повелись (NT) или реально была нужна (сановские системы для многопроцссорных платформ) многопоточность.

Процессы - _дёшевы_.

> Нынче в гноме даже несколько экземпляров одного и того же апплета

Внутри любой erlang-овской программы живут сотни и тысячи _дешёвейших_ процессов.

Мы говорим про процессы, или нити? Если про нити - то про пользовательские или ядерные?

> Мы говорим про процессы, или нити?

Не хотелось бы упрекать вас в том, что вы пытаетесь меня поймать, но не могли бы вы уточнить вопрос?

1. Я говорил о том, что

a) В Solaris ядерные нити являются суровой необходимостью.

b) Они дороги и поэтому появляются многоуровневые M:N планировщики, сочетающие ядерные и пользовательские нити.

c) Это сочетание делает _процессы_ невыносимо дорогой вещью.

2. Процессы в erlang - несомненно пользовательские. Но это именно процессы, т.к. они используют только ввод (прием сообщения) и вывод (посылку сообщения).

Каюсь - хотел поймать:) Почти получилось. Зато - Вы ответили на мой вопрос - поэтому мы, наверное, скоро договоримся:)

Ядерные нити в Солярке действительно дороговаты. Поэтому M:N реализации пользовательских нитей необходимы. Кстати, с Линухом, насколько я знаю, тут забавнее. Была реализация M:N - но в последних ядрах (NPTL) снова стало 1:1 (т.е. каждый пользовательский тред имеет голову в ядре) - потому как ребята решили, что цена ядерного треда стала приемлемо дешевой.

_Процессы_ в Солярке дороги в связи с вышеуказанными причинами (и, подозреваю, есть еще другие причины, на связанные с нитями напрямую - например, отдельное адресное пространство кой-чего стОит).

Про ерланг я не понял, извините. Процессы в унихе - все-таки понятие ядерное (ну, я всегда так думал). Может, Вы имеете в виду, что там пользовательские нити?

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

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

Я имел в виду пользовательский процесс :).

А нити (и пользовательские в том числе) имеют доступ к общему (адресному) пространству, процесс же такого доступа не имеет.

> Надо бы нам про терминологию договориться... Для меня процесс, в первую очередь, это отдельное адресное пространство (это не определение, упаси Боже, это одно из неотъемлемых свойств).

Именно. Но когда нет понятия `адреса' такое разделение сделать проще (и не обязательно на уровне ядра).

> И еще некоторое кол-во других ядерных объектов (всякой служебной информации, типа списков открытых файлы и пр.) А для вас?

Не обязательно ядерных. Процесс - это такая фигня, которая принимает данные на вход и выплевывает на выход.

монолитное ядро не подходит для desktop систем?

> Ухх! Вы меня успокоили! Все-таки, не сотни - в пределах пары десятков.

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

> gnome-vfs сделан так, чтобы работать на любом унихе,

Вашими устами да мед пить. Он и под Linux'-ом (не x86) м-м-м... не совсем хорошо работает...

> Я все-таки настаиваю на том, что gnome-vfs - хак (ну, грязный или нет - это вопрос личной оценки:) именно вокруг униксовой семантики файловой системы.

Hurd тоже придерживается POSIX семантики FS. И QNX. Так что это проблема именно "ядерной" VFS.

> Про RPC - это интересно. Расскажите, чем доступные в линухе способы rpc хуже других.

Нет LPC (a.k.a. Solaris doors), нет Secure RPC, нет распределенной памяти... Да и POSIX RPC тоже далек от совершенства, IMHO.

Мечта идиота состоит в том, ВСЕ должно выглядеть, как файл, а то, что это не файл, а какой-нибудь объект в памяти N-го количества хостов, должна знать только ОС.

> Все-таки макос - это микро-ядро

Нет, это не микроядро. Грубо говоря, такой же отхаканный Mach, как и NT.

> с биэсдишной (униховой!) надстройкой,

И еще с двумя, которые к UNIX никакого отношения не имеют.

> NT же, будучи изначально микроядром,

Никогда не была NT микроядром. Почитайте D.A. Solomon, M.E. Russinovich "Inside m$ Windows 2000".

> так и не обзавелось приличной позиксовой системой. Зато подсистема win32 корни в ядро пустила.

Да, вынь32 подсистема -- одна из убийц NT.

Ну и нихрена себе ,воистину неисповедимы треды ЛОРовские. Начали с Gnome, через интеграцию-дезинтеграцию десктопа,закончили вообще архитектурными вопросами, скоро до железа дойдём ... ЗЫ: Там в топике про Gnome beta1 кто-то про интеграцию на низком уровне кричал ... ну, За что боролись ...

И чито вам не ндравится? Может быть ви антэсемит?