Ну я думаю что при таскании окна 30-40% на Centrino 1.7 - это многовато .. Еще раз напомню что у меня K6-2 500Mhz и я сравниваю с аналогичными операциями в KDE ... Спрашиваете зачем изменять размер тулбаров ? Видно вы не видели Evolution на 15` мониторе 8))

Tochno tak zhe iz arhivov sid u menia gnome - nichego ne tormozit. ;-)

Iz optimizacii bil sdelan prelink (iz odnoimennogo paketa) i vkluchen hdparm

Kstati servak freedesktopovcev uzhe bistree rabotaet, chem xfree, po krainei mere s gnome i vidiahoi nvidia (server Xnvidia). Osobenno zametno eto na gnome-terminal i mplayer ;-)

Skoree bi oni prichesali ego i vipustili reliz - togda nvidia (po sluham s ih forumov) sdelaut draiver pod nego (kdrive) i voobshe rulez budet.

A atishniki uzhe zazhigaut!!! ;-)

Короче, не поленился, запустил top. Выяснил, что gkrellm меня слегка обманывал (точнее, у меня тогда проц был занят другой работой). Изменение загрузки процессора при таскании - в пределах 10%. Даже на 500МГц должно быть не смертельно. Правда, гном из серии 2.5.

Еву я пользую давно. И монитор у меня на лаптопе 15'. Разрешение 1600х1050. Раньше (на том лаптопе, который р3-800) было 1280х1024 - и тоже не жаловался.

На самом деле, я спрашивал, зачем менять размер тулбаров индивидуально для отдельных приложений. А массово - если мне изменяет склероз, можно темочку подкрутить.

linux IS shit

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

Ну и толку? Как ты сможешь продолжить свою работу, если свалится драйвер видяхи или стек TCP? Меня вот не утешает, что ядро продолжает работать, если упали иксы вместе с результатами моего труда.

>не надо вообще перезагружаться никогда

А-а-а врубился, у нас ведь updike рулит, да?

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

Перегрелся на весеннем солнышке?

Возвращаясь к теме гнома не могу не привести цитату из недавней статьи-обзора 2.6

The pop up menu in the Window List applets seems to have two extra options - one for putting the selected window in all workspaces, and another for sending the window to a specified workspace. On clicking on the titlebar of an app window, I noticed a new option - "On Top". Yay!!

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

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

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

Вот интересно - обидится ирси или нет?:) Наверное, обидится.

"никаких успехов". Наутилус в 2.6 был изрядно изменен (тот самый spatial browsing - это ж не просто смена кнопок, это концепция!) Гнумерик и абиворд растут и хорошеют (при том, что Микс все теснее интегрирует ООо в гном:). Мультимедийная составляющая (gstreamer) тоже растет и развивается. Печать (я не сравниваю с кде, я давно его не видел) тоже вперед двигается, интерфейс с cups уже есть и пр. Про диалог выбора файлов Вы откровенно передергиваете. Разговоры об этом шли, начиная с 2.0. Просто ребята хотели 7 раз отмерить (кстати, у них еще раза 3 осталось в запасе, если считать стабильные базовые релизы с 2.0 по 2.6) - это их право. Так что совсем не "только в 2.6 дошло".

Если _Вам_ нужно скопировать файл, Вы выберете то, что Вам близко и знакомо (как и все мы - для себя). А там какие-то "черепа" (как говорил наш куратор на военной кафедре про ученых) от узабилити исследовали и установили, что этот самый spatial очень _нагляден_ и понятен простым пользователям. Спорный тезис? Сколько угодно. Проведите ответное исследование и докажите обратное - мы почитаем и обсудим. Если на английском напишете - еще лучше, заткнете рот выскочкам из Бостона:)

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

Да, и за что при всем этом досталось модульности гнома - я вааще не понял.

загляните на проект GnomeStorage ... вот такие будут файловые мэнеджеры в уже ближайшие годы

>Вот интересно - обидится ирси или нет?:) Наверное, обидится.

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

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

Не хочу опять ломать копья по поводу удобности да и перехватить контракт у этих самым бостонских ребят у меня вряд ли получится, но когда в XXI веке не помещаются надписи на кнопках, а сами кнопки разбросаны по виджету произвольным образом - это позор. Я имею в виду sidebar у наутилуса в 2.4. В 2.6 я так понимаю его вообще убрали, да? Если в свойствах файла есть вкладка комментарии, то вполне логично при выборе в сайдбаре вида "комментарии" увидеть именно их. Но мы видим пустоту. Неужели это так сложно реализовать?

Модульность гнома меня не волнует, но право смешно выдавать это за преимущество, если теперь собрать гном без скриптов (которых уже штуки три минимум) довольно нудное и долгое занятие.

>вот такие будут файловые мэнеджеры в уже ближайшие годы

файловый менеджер для меня на ближайште годы называется konsole

freedesktop.org

Да, думаю, что freedesktop.org будет одним из интересных форков xfree86. Есть, кстати, в рамках этого проекта одна весьма интересная инициатива. Называется она XCB/XLB (X C Binding/X Library Binding), которая призвана заменить xlib. И, кстати, от этого всякие графические тулкиты (тот же GTK+) только выиграют!

xlib - огромный кусман кода, который является слишком большим укрупнением протокола X, производит всякое кэширование и пр. Размер у библиотеки сравнительно большой, что ставит преграду перед эффективным использованием ее, скажем, в PDA. Есть также сложности при написнии многотредных приложений с xlib. Там, оказывается, не все очевидно. Предлагается теперь по ряду очень веских причин разделить его на две части. Первая часть - это биндинг для C X-протокола на самом низком его уровне. Этот биндинг позволит тулкитам напрямую без посредничества xlib работать *непосредственно* с протоколом и производить необходимые именно данному тулкиту действия. Для старых приложений сделан биндинг над XCB, который называется XLB, и который эмулирует API xlib. К тому же, XCB спроектирована так, что позволит разработчикам без труда делать расширения для X-сервера. Раньше написание любого расширения требовало влезания в xlib, насколько я понял, что сильно затрудняет управляемость проектов. Теперь проще будет писать многотредные приложения. К тому же, иксовые приложения теперь смогут использовать стандартные сишные функции динамического выделения памяти вместо тех, что были в xlib. Это даст возможность отслеживать утечки памяти, что было непросто в случае использования xlib.

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

Кому интересно, то там где-то валяется pdf с материалами для конференции по XCB/XLB. Там хорошо все объяснено, как теперь все планируется. Есть также весьма схематичное, но какое-то описание нового API XCB на сайте freedesktop.org.

З.Ы. Проекту XCB/XLB, по-моему, уже два года (или больше?). В сервере freedesktop.org уже используется XCB или еще нет? Кто знает? Ясно одно - ни GTK+, ни QT еще не переписывали под него, поэтому еще рано судить о достигнутых результатах... Но я думаю, что он еще быстрее заработает, чем прежде :)

freedesktop.org

Вот линк. http://www.freedesktop.org/Software/xcb

Надписи на кнопках, ладно. Просто надписи не влезают, т.е. английская лезет, а под русскую почему-то никак не раздвинуть.

Когда гном (и прочие) начнет работать без костылей, тогда не надо будет говорить про платформу.

4svu: Насчет винмодема - про патч для редхат расскажи, а то рассказ неполным получается.

>Я в принципе конечно ничего против разработчиков гнома не имею, но раз уж они приватизировали право на бизнес-десктоп и прибрали к рукам финансирование, то могли бы мерять и побыстрее.

Насчет финансированиия, это точно на солнце долго греться пришлось.

Gnome финансируется в основном редхатом (еще немного сан и химиан).

Кде финансируется тролтечем сусе линдовсом и другими.

Где здесь "прибрали к рукам", объясни мне глупому? КДЕ сейчас на западных форумах активно орут: "у нас больше ресурсов".

to svu:

Еще раз соорри за оффтопик

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

Мммддаа, к сожелению это мне не поможет. У меня модем Supra 56i CW
с чиопм HCF от Conexanta. Производитель Diamond Multimedia.
Я конечно понимаю, что можно поставить дрова от linuxanta, но хотелось
бы решить не платя доп. 20 баков.
Нашел вот ссылку http://ndiswrapper.sourceforge.net/. Говорят, что
загрузчик драйверов у них такой же как и у линуксанта и способен
загрузить бинарные дрова от винды. Пока не пробовал, сегодня вечером
попробую.

А чего про него рассказывать? Я же рассказал основные куски. Во-первых, "основа" патча лежит внутри slmodem-2.9.6.tar.gz. Далее, выясняется, что бОльшая часть патча уже лежит в редхатовских ядрах - реально нужно только то, что запихивает intel-8x0m в конфигурацию ядра - и сам новый файл intel-8x0m.с Но при этом та версия файла, которая в патче - старая. Нужно взять новую из последней алсы.

Ну не постить же мне окончательный патч прямо сюда, народ, он все-таки не 2 байта.

Вообще, подождите немного - этот модуль уже включен в последние rpm от arjan (кстати, можете прямо оттуда прямо сейчас и взять). И скоро появится в федоровских rpm.

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

и чего это туповатых подростков так сюда тянет?.. у тебя что в школе психолога нету? или медсестры которая выпишет направление?

> Gnome финансируется в основном редхатом (еще немного сан и химиан).

> Кде финансируется тролтечем сусе линдовсом и другими.

Теперь вспоминает, что сусе и химиан нынче одно и то же:) И думаем, пойдет ли Новел направо или налево:)

Если серьезно, я тоже сомневаюсь, что гном прибрал именно все ресурсы. КДЕ весьма силен.

что стыдно перед окружающими у били отсасывать? :)

и нифга это неудобно. надо запоминать кучу прототипов. а в позиксе - один принцип а не куча фактиков.

про рулезность uptime'-ов

> >не надо вообще перезагружаться никогда

> А-а-а врубился, у нас ведь updike рулит, да?

Когда появляется на securityfocus сообщение о дыре в ядре, а на машине вот уже третью неделю считается задачка, вот тогда и врубаешься, что uptime'-ы рулят.

CORBA vs write()

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

Дык это ж и есть [почти] OO RPC. Идея трансляторов как раз в том и состоит, чтоб предоставить интерфейс к _любому_ сколь угодно сложному IO|IPC|RPC в виде POSIX-подобных опреций с файлами.

Напр., можно gconf представить в виде ФС ( имя файла -- имя ключа, значение ключа -- содержимое файла). Тогда ключ менять можно просто: cat > /servers/gconf/applications/blah/blah

CORBA vs write(), очепятки

%s/опреций/операций/g

> к _любому_ сколь угодно сложному IO|IPC|RPC в виде POSIX-подобных опреций с файлами

Вы действительно верите, что это возможно - запихать семантику сколь угодно сложного интерфейса в парадигму файловой системы - при этом сделать это прямо, естественно, без извращений, эффективно? У меня есть сильные сомнения. ОО интерфейсы слишком разнообразны, чтобы так просто их можно было "сплющить". Да традиционная файловая система и сама не справляется обходиться без ioctl (а дальше уж кто во что горазд), если уж на то пошло - что, опять же, демонстрирует неполноту идеи read/write.

Да, а еще Вы рискуете дойти до того, что Ваша файловая система просто ляжет под непосильным грузом псевдо-файлов (понятно, я не про диск - я про структуры ядра на уровне vnode). Т.е. требуется нехилое перетряхивание основ ФС ОС, чтобы это все работало эффективно. Возможно, переписывание ОС с нуля (и превращение ее в тот же plan9, в котором действительно "все есть файл").

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

Запости мне на мыло - я хочу этот вопрос включить в faq. Сам понимаешь - там надо все разжеванно и подробно.

а где мне взять Ваше мыло? Киньте мне на svu at gnome dot org вопросик - я вечерком сделаю (постараюсь).

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

Да.

> ОО интерфейсы слишком разнообразны, чтобы так просто их можно было "сплющить"

Не надо ничего сплющивать. Объект -- директория, свойство -- файл в этой директории, etc.

> Да традиционная файловая система и сама не справляется обходиться без ioctl (а дальше уж кто во что горазд), если уж на то пошло - что, опять же, демонстрирует неполноту идеи read/write.

Нет, это как раз демонстрирует неполноту ее реализации (раз есть вещи, недоступные через read/write)

> Да, а еще Вы рискуете дойти до того, что Ваша файловая система просто ляжет под непосильным грузом псевдо-файлов (понятно, я не про диск - я про структуры ядра на уровне vnode).

VFS работает в userspace. И псевдо-файлов никаких нет.

> и превращение ее в тот же plan9, в котором действительно "все есть файл"

А чем это плохо?

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

1) Понятие "просто UNIX" меняется со временем.

2) А какая разница? Наружу все равно торчит POSIX-образное API.

>Теперь вспоминает, что сусе и химиан нынче одно и то же:) И думаем, пойдет ли Новел направо или налево:)

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

Ок. Вообще оно тут периодически везде всплывает.

> Объект -- директория, свойство -- файл в этой директории

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

> Нет, это как раз демонстрирует неполноту ее реализации (раз есть вещи, недоступные через read/write)

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

Да, если VFS в user space, конечно, ядру наплевать. Хотя даже на пользовательскую VFS нагрузочка может получиться немаленькая. Проц-то у нас один (или будем добавлять спец проц - как у next, только для файловых операций, а не dps?:) Соббсно, мысль моя в том, что программеру придется мучится сначала "укладывая" выпуклый ОО интерфейс в последовательность чтений-записей, а потом выполнять обратную работу (на стороне сервера-транслятора) - переводить потоки данных в вызовы к внутреннему объекту.

> > и превращение ее в тот же plan9, в котором действительно "все есть файл"

> А чем это плохо?

Ничем. Только plan9 - это не уних. Гном - униховый десктоп. Только и всего. Неувязочка.

> 1) Понятие "просто UNIX" меняется со временем.

Не согласен. Еще можно подумать, что меняется понятие "современный уних". Но понятие "просто уних" (в смысле "классический уних") - стабильно. И было сформировано в первые 5-10(-15?) лет существования.

> Наружу все равно торчит POSIX-образное API.

Ну, такое API и в винюках есть. Только это не делает их унихом. Дело не в этом. А в том, что гном не имеет права рассчитывать на существование такого API (не в смысле наличия функций, а в смысле семантики, которая за ними). Он может рассчитывать только на обычные файлы и каталоги, симлинки, файлы устройств. Даже на /proc он рассчитывать не имеет права, в общем случае.

Повторяю, Гном - униховый десктоп. И он использует то хорошее, что есть в унихе, обходя по возможности те унаследованные проблемы, которые в нем тоже есть. И не имеет права на "а вот если бы..."

О, svu, я тоже хочу мыло на gnome.org :) Расскажи, как получить :)

> А с методами-то что делать будем?

Тоже самое -- все есть файл.

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

cat /servers/gnome-vfs/panel/applets/all

:)

> метод, возвращающий апплет на позиции idx?

stat называется. Файл и директория -- это одно и то же :))

> Особенно с теми, которые и принимают, и возвращают значения?

А в чем проблема-то?

write -- принимаем значение, read -- отдаем результат. Где проблема-то?

> Ничем. Только plan9 - это не уних. Гном - униховый десктоп. Только и всего. Неувязочка.

Т.е., портировать GNOME например, на Hurd никто не собирается?

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

Как раз именно для этого VFS и создавалась. Только тот факт, что она рвботала внутри ядра, практически сводит на нет ее преимущества.

> Соббсно, мысль моя в том, что программеру придется мучится сначала "укладывая" выпуклый ОО интерфейс в последовательность чтений-записей, а потом выполнять обратную работу (на стороне сервера-транслятора) - переводить потоки данных в вызовы к внутреннему объекту.

1) А IDL уже отменили?

2) А CORBA|DCOM чем лучше?

> Ну, такое API и в винюках есть.

> Ну, такое API и в винюках есть. Только это не делает их унихом.

Да, потому что есть "более равная" win32 подсистема.

> А в том, что гном не имеет права рассчитывать на существование такого API (не в смысле наличия функций, а в смысле семантики, которая за ними).

... и поэтому сам занимается реализацией такой семантики. И KDE делает то же самое. И (казалось бы, что общего у desktop environment и системы обработки данных) ROOT ( См. http://root.cern.ch). И даже у убогого mc есть своя VFS. Вам не кажется, что неправильно?

Ежики кололись, плакали, но продолжали жрать кактус. :(

> Даже на /proc он рассчитывать не имеет права, в общем случае.

И на X window system, потому как она не POSIX :)

Взятки:) Да нет, просто попросил - и мне сделали.

Про апплеты понял. Да, неудачный пример:)

> А в чем проблема-то? write -- принимаем значение, read -- отдаем результат. Где проблема-то?

А если два процесса одновременно будут читать из одного файла, после записи в него же? race conditions не боимся?

> Т.е., портировать GNOME например, на Hurd никто не собирается?

Наверное, собирается кто-нибудь. Только приоритет у этой задачи... И заниматься крупной перемолоткой нижнего уровня, боюсь, никто не будет. Ограниченность ресурсов, знаете ли.

> 1) А IDL уже отменили?

> 2) А CORBA|DCOM чем лучше?

Ура. Если IDL спрячет от меня все эти богатства OO FS-RPC и оставит мне корбу или любой другой нормальный call-based OO API - я согласен на все:)

> И даже у убогого mc есть своя VFS. Вам не кажется, что неправильно?

Да, это перебор. Поэтому я смотрю на freedesktop.org - единственное место, где смогут договориться о чем-то подобном и реализовать. Если смогут, конечно.

> И на X window system, потому как она не POSIX :)

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

s/расшерения/расширения/

Дык, кого попросил-то :)?

Точно не помню. Может быть, Кристиан. А может, просто accounts at gnome dot org

> и оставит мне корбу или любой другой нормальный call-based OO API

Call-based API -- нормальный? Мсье знает толк в извращениях...

> Поэтому я смотрю на freedesktop.org - единственное место, где смогут договориться о чем-то подобном и реализовать.

Такая функциональность нужна не только -- и не столько -- разного рода desktop environment'-ам.

> Она, кстати, вроде, IEEE - или я чего-то путаю?

Вы чего-то путаете.

А почему call-based API - извращение? И давно это стало извращением? Как-то я отстал от жизни...

Ну, под десктопом лежит много чего. Например, libxml, pkgconfig - они, хоть и на freedesktop.org, полезны не только на десктопе.

Да, про IEEE это я погорячился. Дело ограничивается X Consortium (известным нынче как x.org)

Да, про атомарный read_write есть решение в рамках классической семантики, но с временными файлами. Но Боже, какой же это изврат!!!

2Анонимус

Ну так сравни возможности редхета и сана с возможностями суси, тролей и линдовса. Если не ошибаюсь процентов 70 денег на линух рынке загребает именно красношляп.

2DSelect

>Когда появляется на securityfocus сообщение о дыре в ядре, а на машине вот уже третью неделю считается задачка, вот тогда и врубаешься, что uptime'-ы рулят.

А зачем на такую машину пускать посторонних?

>Ну так сравни возможности редхета и сана с возможностями суси, тролей и линдовса. Если не ошибаюсь процентов 70 денег на линух рынке загребает именно красношляп.

Ну, во-первых ресурсы красношляпа идут на массу других проектов: начиная от gcc и ядра, и заканчивая мозиллой.

70% - явный перебор (на сегодняшний день).

Кроме того, про сусе и линдовс может быть, но про троллей? C их бешенными ценами на тулкит у них должны быть (и есть насколько я знаю) очень приличные бабки, и они платят зарплату многим разработчикам кде.

> А зачем на такую машину пускать посторонних?

1) Задачка не моя, а юзверьская...

2) Из 1) следует, что их туда как-то пускать надо

> Да, про атомарный read_write есть решение в рамках классической семантики, но с временными файлами.

Не нужно таких извращений.

http://i30www.ira.uka.de/teaching/coursedocuments/80/mkc-05.pdf

Посмотрел быстро. Ну, местами интересно. Как решается проблема атомарного read/write на файловой системе, не понял. Буду смотреть еще раз, медленно:).

2BaT:
> О, svu, я тоже хочу мыло на gnome.org :) Расскажи, как получить :)
У тебя ж есть право на запись в репозиторий, значит, есть и алиас на gnome.org ровно с твоим логином.

В общем случае, это несвязанные вещи. Во всякому случае, мыло я получил сильно позже, чем доступ к cvs