anonymous@RULINUX.NET~# | Last login: 2024-11-14 20:30:23 |
Регистрация Вход | Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск |
Форум - Talks | [RSS] |
Интересно, люди которые жалуются, что ssh -X медленнее, чем VNC, слышали про такую опцию? А ведь она здорово оживляет тунеллирование Х-протоколf сквозь ssh ...
anonymous(*) (2010-06-14 20:01:00)
Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2
|
|
|
bugmaker(*)(2010-06-14 20:37:39)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100407 Ubuntu/9.04 (jaunty) Shiretoko/3.5.9 |
Скрыть
Re: ForwardX11Trusted> Типа, добавить на Х-сервер какой нибудь XToolkitExtension, где бы одним запросом с клиента на сервер отрисовывался бы сразу готовый виджет?
|
Tux-oid(*)(2010-06-14 21:03:03)
Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 |
Скрыть
Re: ForwardX11TrustedНу, на PDA может и вообще сервер не нужен - одного фреймбуффера достаточно, поскольку там приложение держит весь экран практически эксклюзивно. А если мы не хотим графику в ядре - значит нужен демон, который регулирует доступ к физическому ресурсу. А если это демон, то сделать протокол обращения к нему сетевым - это просто очевидный побочный эффект. Ну, а как только на мобилках появится многозадачность - то сразу им и понадобится что-то типа Х-сервера. Причем ,казалось бы, можно было бы перехерачить сервер под конкретную платформу так чтоб виджеты не только на экран влезали, но и вплоть до отрисовки их в своем корпоративном look-and-feel-a, и пускать приложения написанные под XToolkitExtension практически без изменений. anonymous(*)(2010-06-14 21:18:14)
Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2 |
anonymous(*)(2010-06-14 21:20:53)
Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2 |
Скрыть
Re: ForwardX11TrustedЯ думаю, что программисты не те (что были в MIT в коне восьмедисятых) пошли. Чтоб протокол писать - это ж надо над спецификациями корпеть, а так раз - и вперед либу быдлокодить! anonymous(*)(2010-06-14 21:30:36)
Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2 |
Скрыть
Re: ForwardX11Trusted> Ну, на PDA может и вообще сервер не нужен
> А если это демон, то сделать протокол обращения к нему сетевым - это просто очевидный побочный эффект.
> Ну, а как только на мобилках появится многозадачность - то сразу им и понадобится что-то типа Х-сервера.
> Причем ,казалось бы, можно было бы перехерачить сервер под конкретную платформу так чтоб виджеты не только на экран влезали, но и вплоть до отрисовки их в своем корпоративном look-and-feel-a, и пускать приложения написанные под XToolkitExtension практически без изменений.
|
Скрыть
Re: ForwardX11TrustedОх разве? Протоколов-то навалом, начиная с http, только они все расчитаны на толстых клиентов. А всё потому что проц сотворить оказывается дешевле, чем жырные каналы связи. bugmaker(*)(2010-06-14 23:00:32)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100407 Ubuntu/9.04 (jaunty) Shiretoko/3.5.9 |
Скрыть
Re: ForwardX11TrustedНо толщина канала растет быстрее, чем скорость процев - примерно как 3 к 2. Поэтому и становится выгодным пересылать несжатый снимок экрана по сети. А было б наоборот - то мы б уже сейчас имели экраны с dpi по 300 и не о какой пересылке по сети речи бы не было (также как и никому не было бы интересным субпиксельное сглаживание). И раз ты http упомянул, пока графические тулкиты стремились эмулировать венду, веб-интерфейсы уже сейчас сильно их потеснили. И почему-то вебдизайнеров мало волнует, что они не могут контролировать каждый пиксел браузера. Единственное, что мешает быстрой и безболезненной смерти тулкитов - что не будешь же на каждый комп апач ставить. А расширением Х-протокола можно было бы сделать так, как если бы нечто наподобии апача уже встроено в Х-сервер! И кто его знает, если дела и дальше с этой CUDA пойдут как сейчас, то может оказаться выгодным переписать X-сервер под куду так, чтоб все графические объекты хранились в графической памяти, да и сам он на видеопроцессоре крутился, отдельно от ядра. Вот тогда и окажется, что иметь графическую систему вне ядра - это офигенное конкурентное преимущество? anonymous(*)(2010-06-15 02:24:19)
Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2 |
Скрыть
Re: ForwardX11Trusted>>тебе придётся переделывать стандарт под Жопса
anonymous(*)(2010-06-15 03:09:38)
Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2 |
Скрыть
Re: ForwardX11Trusted> Но толщина канала растет быстрее, чем скорость процев - примерно как 3 к 2
> Поэтому и становится выгодным пересылать несжатый снимок экрана по сети.
> мы б уже сейчас имели экраны с dpi по 300
> И раз ты http упомянул, пока графические тулкиты стремились эмулировать венду, веб-интерфейсы уже сейчас сильно их потеснили.
> вебдизайнеров мало волнует, что они не могут контролировать каждый пиксел браузера.
> А расширением Х-протокола можно было бы сделать так, как если бы нечто наподобии апача уже встроено в Х-сервер!
> И кто его знает, если дела и дальше с этой CUDA пойдут как сейчас, то может оказаться выгодным переписать X-сервер под куду так, чтоб все графические объекты хранились в графической памяти, да и сам он на видеопроцессоре крутился, отдельно от ядра. Вот тогда и окажется, что иметь графическую систему вне ядра - это офигенное конкурентное преимущество?
|
Скрыть
Re: ForwardX11TrustedВот от этого веб-девелоперы уже как настонались: под одним браузером одно, под другим - другое. В результате либо приложение золотое выходит и каждый браузер обслуживает персонально, или получается здоровый минимализм, который в экстремуме тоже обходится дорого, потому как поди спроектируй такой интерфейс, который хорошо бы работал и смотрелся и под ИЕ и под мозилой и под оперой, то же без флеша, то же без джава-скрипта, то же без чего-то ещё. А между этими точками - сплошное разнообразно глючащее говно. Хотя я этому только рад, иначе не было бы уже нормальных гипертекстовых сайтов, была бы какая-нибудь вебванольная поебень, а то и вовсе задээрэмленный флешь. |
Скрыть
Re: ForwardX11Trusted>>способный чота делать с Х протоколом?
>>Ты про сеть забыл.
>>Это решение от бедности - малые скорости передачи данных, что ещё хуже - латентность.
А вот если бы послушались меня, то тогда бы нас обвиняли, что это мы хотим поработить мир, а мы бы тихо-мирно продолжали бы фиксить баги в ХToolkitExtension и, поплевывая, отвечали бы: "Да хотим ... А Жопс с Болмером у нас в отделе маркетинга на посылках будут... " anonymous(*)(2010-06-15 09:38:09)
Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2 |
Скрыть
Re: ForwardX11Trusted> А зачем быдлокодеру чо-та делать с Х протоколом? .. клепал формочки под gtk ..
> Одна нить на центральном процессоре в роли менеджера и на приеме входящих соединений, а все остальные на ядрах видеопроцессора. В куде же всё именно так и сделано.
> Ага, Сережа Брин от бедности придумал в ГуглеХроме весь гуй в бравзере реализовать. Видимо, поэтому все, кто хотел гуй в ядре и считал, что сеть слишком медленная среда для графики, теперь бьтся в истерике и с пеной у рта обвиняют его, что он хочет поработить мир.
> А вот если бы послушались меня ...
|
Скрыть
Re: ForwardX11Trusted> Но толщина канала растет быстрее, чем скорость процев - примерно как 3 к 2. Поэтому и становится выгодным пересылать несжатый снимок экрана по сети.
> И раз ты http упомянул, пока графические тулкиты стремились эмулировать венду, веб-интерфейсы уже сейчас сильно их потеснили. И почему-то вебдизайнеров мало волнует, что они не могут контролировать каждый пиксел браузера.
> Единственное, что мешает быстрой и безболезненной смерти тулкитов - что не будешь же на каждый комп апач ставить. А расширением Х-протокола можно было бы сделать так, как если бы нечто наподобии апача уже встроено в Х-сервер!
bugmaker(*)(2010-06-15 16:02:38)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100407 Ubuntu/9.04 (jaunty) Shiretoko/3.5.9 |
Скрыть
Re: ForwardX11Trusted> нагрузку на проц выгоднее распределить, то есть дешевле N толстых клиентов и в меру мощный сервер, чем
Не дешевле. Во-первых на клиентах можщности будут простаивать как и на любом другом десктопе. Да там нужны мощности для более быстрого исполнения задач, для уменьшения времени отклика интерфейса, но 90% времени они всё равно исполняют команду хальт. При этом повышение мощности клиентских устройств влечёт за собой связанные расходы: повышение расхода энергии и отвод тепла, в которое эта энергия в конечном счёте уходит вся без остатка, что в свою очередь влечёт за собой более дорогие схемы питания и всякие ненадёжные и шумные кулеры. К тому же при перемещении обработки на клиента потребуется и память в бОльших количествах. => Такие схемы дороги и менее надёжны. А вот если всё переселить в один ВЦ, сам ВЦ расположить в географически благоприятном месте - во льдах Гренландии, заполярье или Антпарктиде - то мы уже сразу выигрываем в охлаждении. Дальше, этот сервер будет у нас системой массового обслуживания, которая в принципе никогда не будет нагружена на 100%. Если мы исходим из предположения, что юзер использует в среднем только 10% мощности CPU, то следовательно на сотню юзеров ВЦ нам теоретически потребуется всего 10 процов, что уже охрененная экономия. Но, естественно, такого гладкого распределения никогда не добьёшься, и процентов 20 экономии процов уже будет неплохо. Другие факторы: централизованное обслуживание, стабильность окр. среды в ВЦ положительно скажутся на продолжительности эксплуатации компонентов, прочие разделяемые ресурсы будут сэкономлены по тому же принципу как и CPU. Плюс мы получаем возможность максимально быстрого и надёжного взаимодествия клиентских программ - они же сидят в одном компе, плюс мы получаем надёжность: клиент может нестись на своём авто по горным туннелям Италии периодически отпадая от сети, спускаться на лыжах с гор в Швейцарии то и дело налетая на тамошние деревья, разбивая при этом клиентский девайс вдрызг и переподключаясь к своей же сессии, безмятежно продолжающей жить на удалённом сервере, или он может например мчаться на Хаммере по безлюдным пустыням Афганистана, периодически подрываясь на минах, подложенных коварным противником и тогда другой боец из его отряда сможет подключиться к его сессии и продолжить управление гигантскими боевыми человекоподобными нанороботами что бы довести до успешного завершения начатую боевую операцию... Много каких применений можно придумать, но главное - это возможность централизованно контролировать деятельность пользователей прямо на сервере и иметь возможность прямо по месту пресекать экстремизм и обмен нелицензионным контентом. |
Скрыть
Re: ForwardX11TrustedНе проканает. Во-первых объективный фактор - возможности современных сетей недостаточны. Во-вторых субьективный фактор - общество ещё не готово к тотальному контролю и цензуре с моей стороны. Хотя в этом плане я с оптимизмом смотрю в будущее - объединёнными усилиями политиков всех стран ( напр http://www.lor-ng.org/message.php?newsid=7316&fid=9&page=0#60275 ) рано или поздно удастся избавиться от гнёта свобод, гарантироыванных конституцией, а там уже когда народ пообвыкнется, останется только технически реализовать подобную систему. Пусть Гуууугл сперва шишек набьёт в этой сфере :) |
|
|
|
Этот тред читают 5 пользователей: |
Анонимных: 5 Зарегистрированных: 0 |
Re: ForwardX11Trusted
И почему, действительно, раз тулкитостроители жалуются, что графические примитивы слишком примитивные, не пошли по пути расширения протокола? Типа, добавить на Х-сервер какой нибудь XToolkitExtension, где бы одним запросом с клиента на сервер отрисовывался бы сразу готовый виджет? Вместо этого пошли по пути перекладывания растеризации на клиента (freefont - это было только начало).
Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4) Gecko/20070601 SeaMonkey/1.1.2