Во-первых объективный фактор - возможности современных сетей недостаточны.

Во-вторых субьективный фактор - общество ещё не готово к тотальному контролю и цензуре с моей стороны. Хотя в этом плане я с оптимизмом смотрю в будущее - объединёнными усилиями политиков всех стран ( напр  http://www.lor-ng.org/message.php?newsid=7316&fid=9&page=0#60275 ) рано или поздно удастся избавиться от гнёта свобод, гарантироыванных конституцией, а там уже когда народ пообвыкнется, останется только технически реализовать подобную систему. Пусть Гуууугл сперва шишек набьёт в этой сфере :)

Не дешевле. Во-первых на клиентах можщности будут простаивать как и на любом другом десктопе. Да там нужны мощности для более быстрого исполнения задач, для уменьшения времени отклика интерфейса, но 90% времени они всё равно исполняют команду хальт. При этом повышение мощности клиентских устройств влечёт за собой связанные расходы: повышение расхода энергии и отвод тепла, в которое эта энергия в конечном счёте уходит вся без остатка, что в свою очередь влечёт за собой более дорогие схемы питания и всякие ненадёжные и шумные кулеры. К тому же при перемещении обработки на клиента потребуется и память в бОльших количествах. => Такие схемы дороги и менее надёжны.

А вот если всё переселить в один ВЦ, сам ВЦ расположить в географически благоприятном месте - во льдах Гренландии, заполярье или Антпарктиде - то мы уже сразу выигрываем в охлаждении. Дальше, этот сервер будет у нас системой массового обслуживания, которая в принципе никогда не будет нагружена на 100%. Если мы исходим из предположения, что юзер использует в среднем только 10% мощности CPU, то следовательно на сотню юзеров ВЦ нам теоретически потребуется всего 10 процов, что уже охрененная экономия. Но, естественно, такого гладкого распределения никогда не добьёшься, и процентов 20 экономии процов уже будет неплохо. Другие факторы: централизованное обслуживание, стабильность окр. среды в ВЦ положительно скажутся на продолжительности эксплуатации компонентов, прочие разделяемые ресурсы будут сэкономлены по тому же принципу как и CPU. Плюс мы получаем возможность максимально быстрого и надёжного взаимодествия клиентских программ - они же сидят в одном компе, плюс мы получаем надёжность: клиент может нестись на своём авто по горным туннелям Италии периодически отпадая от сети, спускаться на лыжах с гор в Швейцарии то и дело налетая на тамошние деревья, разбивая при этом клиентский девайс вдрызг и переподключаясь к своей же сессии, безмятежно продолжающей жить на удалённом сервере, или он может например мчаться на Хаммере по безлюдным пустыням Афганистана, периодически подрываясь на минах, подложенных коварным противником и тогда другой боец из его отряда сможет подключиться к его сессии и продолжить управление гигантскими боевыми человекоподобными нанороботами что бы довести до успешного завершения начатую боевую операцию... Много каких применений можно придумать, но главное - это возможность централизованно контролировать деятельность пользователей прямо на сервере и иметь возможность прямо по месту пресекать экстремизм и обмен нелицензионным контентом.

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

> Единственное, что мешает быстрой и безболезненной смерти тулкитов - что не будешь же на каждый комп апач ставить. А расширением Х-протокола можно было бы сделать так, как если бы нечто наподобии апача уже встроено в Х-сервер!
Почему нет? Ну на самом деле не тот самый, а какой-нибудь примитивный сервачёк, который в состоянии выдавать с одной стороны хмл через пайп, и с другой стороны библиотека, способная его отрисовать. И почти такие есть уже, вот глянь glade и gtk-server.

> Одна нить на центральном процессоре в роли менеджера и на приеме входящих соединений, а все остальные на ядрах видеопроцессора. В куде же всё именно так и сделано.
При чём здесь CUDA? Проблема не в быстром запихивании данных в видяху, а в их доставке клиенту. Если вместо текста ты кидаешь на клиента картинку - оно будет тормозить. Если каждый чих пользователя отрабатывается удалённо - оно будет лагать.

> Ага, Сережа Брин от бедности придумал в ГуглеХроме весь гуй в бравзере реализовать. Видимо, поэтому все, кто хотел гуй в ядре и считал, что сеть слишком медленная среда для графики, теперь бьтся в истерике и с пеной у рта обвиняют его, что он хочет поработить мир.
Он разве предлагал серверную часть в опенсорц?

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

>>Ты про сеть забыл.
А чё сеть? Одна нить на центральном процессоре в роли менеджера и на приеме входящих соединений, а все остальные на ядрах видеопроцессора. В куде же всё именно так и сделано.

>>Это решение от бедности - малые скорости передачи данных, что ещё хуже - латентность.
Ага, Сережа Брин от бедности придумал в ГуглеХроме весь гуй в бравзере реализовать. Видимо, поэтому все, кто хотел гуй в ядре и считал, что сеть слишком медленная среда для графики, теперь бьтся в истерике и с пеной у рта обвиняют его, что он хочет поработить мир.

А вот если бы послушались меня, то тогда бы нас обвиняли, что это мы хотим поработить мир, а мы бы тихо-мирно продолжали бы фиксить баги в ХToolkitExtension и, поплевывая, отвечали бы: "Да хотим ... А Жопс с Болмером у нас в отделе маркетинга на посылках будут... "

> Поэтому и становится выгодным пересылать несжатый снимок экрана по сети.
Не становится.

> мы б уже сейчас имели экраны с dpi по 300
Сеть тут ни при чём. Капиталисты будут отдавливать из себя разрешение экранов по чайной ложке в год. Им же не выгодно дать тебе всё сразу. Пусть лучше ты будешь каждый год покупать новый, чуть более лучший девайс, чем дать тебе всё сразу и закрывать фирму.

> И раз ты http упомянул, пока графические тулкиты стремились эмулировать венду, веб-интерфейсы уже сейчас сильно их потеснили.
Это решение от бедности - малые скорости передачи данных, что ещё хуже - латентность. Когда по сетке можно будет подключать монитор непосредственно к удалённому серверу и не ощущать задержек между твоими воздействиями и реакцией среды - персональные вычисления кончатся. Тебя заставят покупать программы как сервис. Это будет всем выгодно - клиент будет стоить копейки, м/б будет функцией телевизора, никаких проблем с кроссплатформенностью, никаких проблем с протоколом - чистое видео, сервер в прямоугольник твоего монитора будет просто рисовать всё, что ему вздумается. И главное - ты уже будешь вынужден платить за каждый чих, типа купите 300 кликов мышков со скидкой в 50%..

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

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

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

И раз ты http упомянул, пока графические тулкиты стремились эмулировать венду, веб-интерфейсы уже сейчас сильно их потеснили. И почему-то вебдизайнеров мало волнует, что они не могут контролировать каждый пиксел браузера. Единственное, что мешает быстрой и безболезненной смерти тулкитов - что не будешь же на каждый комп апач ставить. А расширением Х-протокола можно было бы сделать так, как если бы нечто наподобии апача уже встроено в Х-сервер!

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

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

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

> Причем ,казалось бы, можно было бы перехерачить сервер под конкретную платформу так чтоб виджеты не только на экран влезали, но и вплоть до отрисовки их в своем корпоративном look-and-feel-a, и пускать приложения написанные под XToolkitExtension практически без изменений.
Потом какой-нибудь Жопс скажет, что твои виджеты плохо сочетаются с евоным тачскрином и тебе придётся переделывать стандарт под Жопса. Когда ты его переделаешь, какой-нибудь Болмер завопит что в виджетах, заточенных под тачскрин недоутилизуется мышь, переделывай мол обратно. Потом придёт какой-нибудь лесник с трёхмерным гуем и даст дюлей и тебе и Болмеру и Жопсу.

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

Ну, а как только на мобилках появится многозадачность - то сразу им и понадобится что-то типа Х-сервера. Причем ,казалось бы, можно было бы перехерачить сервер под конкретную платформу так чтоб виджеты не только на экран влезали, но и вплоть до отрисовки их в своем корпоративном look-and-feel-a, и пускать приложения написанные под XToolkitExtension практически без изменений.