В общем виде хорошо распараллелить получается только множество однотипных, мелких задач примерно одного размера.
Задачи должны быть однотипными и примерно одного размера, что бы для любого достаточно большого N, можно было сказать что N одновременно выполняющихся задач создают одинаковую нагрузку вне зависимости от количества экземпляров и планировщик был свободен в выборе.
Задачи должны быть мелкими и примерно одного размера, чтобы обеспечить приемлемое время отклика и не вызывать голодания.
Если условия не выполняются, особо не распараллелишь.
Ещё один важный момент — объём контекста задачи и его уникальность. Известный факт, выключение HyperThreading может заметно повысить производительность SQL Server, так как ядра перестают перетирать общий кеш. WinRAR читает данные с диска и пишет туда же. Если архивировать в сто потоков, скорость только упадёт, так как головка винчестера будет конвульсивно дёргаться, а не читать или писать данные. Какие-то задачи лучше не распараллеливать.
Выскажу свою точку зрения, не претендуя на ее истинность.
Мы по привычке говорим о некотором общем понятии "программирование", не замечая, что под этим термином давно уже сосуществуют задачи совершенно разного вида. Их вообще много, но в применении к проблеме, которую ты озвучил, деление можно провести так : задачи представления данных и задачи обработки данных. Деление, конечно, условно, но ИМХО достаточно четко.
Высоконагруженные распараллеливаемые серверы и всякие сайты — это первый тип. Много запросов (понимайте под ними что угодно) при малой обработке данных. В сущности, задачей таких систем является, по большому счету, данные откуда-то добыть и куда-то представить. При минимальной, если вообще существующей, обработке.
А winrar — второго типа. Запросов мало или очень мало, обработка данных огромная.
Для первого типа наиболее важно обеспечить масштабируемость, интерфейс и скорость. Сделайте нам быстро и красиво. Интерфейс веб-сайтов порядком-таки изменился за десятилетие. Для задач второго типа интерфейс и скорость вообще играют десятую роль. Интерфес winrar, в общем, каким был, таким и остался, и ничего тут нового и не нужно. Не в нем задача. И будет он архивировать за 0.5 сек или 5 сек — в общем, не так уж важно. И масштабируемость совсем не нужна.
А пересечений пока что и нет. Скорее наоборот — эти области все больше расходятся. А когда пытаются их скрестить — получается ублюдок. Все же нельзя в одну телегу этих самых коня и лань...
SV.>P.S. Кассандрствую: лет через 10 этот вопрос приобретет острейшую актуальность.
Здравствуйте, SV., Вы писали:
SV.>P.S. Кассандрствую: лет через 10 этот вопрос приобретет острейшую актуальность.
Через 10 лет у каждого в кармане будет столько CPU power, что разумным будет подход все вычисления туда и сдвинуть, оставив серверу хранение/синхронизацию/обмен данными.
Здравствуйте, SV., Вы писали:
SV.>Не сомневаюсь, что у вас так и будет. Но подумайте о пользователях. Я — не самый из них тупой, и CPU power в моем кармане достаточно, но я не осилил такой задачи, как репликация (на мелкософтном языке — синхронизация) данных между двумя .pst-файлами из большого Аутлука и карманным Аутлуком. Когда спрашиваю знатоков, те делают большие глаза: зачем тебе это? Затем, говорю я, что один файл — моя личная переписка, а второй — рабочая. Роли разные. Рабочую я могу передать вместе с работой, а личную понесу дальше. В ответ хмыкают и пожимают плечами. В конце концов ActiveSync заменили на WMDC, WM приговорили, я плюнул и начал ходить в большой Аутлук через RDC, иногда даже — при помощи карманного CPU power. Или спросите поклонников GMail, почему они, несмотря на море CPU power в своем макбуке, делятся секретами с Корпорацией-Злом. Посчитайте TCO. Наконец, подумайте о тех соблазных, которых вы еще не видели. Вот пока я писал это сообщение, пару раз FireFox закрылся, подозреваю, что выкидывал окошко с предложением обновиться, а я продолжал печатать и нажимал что-нибудь не то. А если бы вся эта память — этакий трепетный конь — хранилась в РБД? Открыл бы я FireFox, а в нем — окошко с формой и моим (потерянным) текстом. И это только если одну минуту подумать.
Вы эта, путаете интерфейс и реализацию
Никто вас, разумеется, отпускать с сервисов типа gmail не собирается. Речь о том, чей процессор будет греться — ваш или гугловый. А интерфейс-то при этом вполне может выглядеть так, будто все на сервере, а у вас лишь окошко "бровсера".
Здравствуйте, SV., Вы писали:
SV.>я не осилил такой задачи, как репликация (на мелкософтном языке — синхронизация) данных между двумя .pst-файлами из большого Аутлука и карманным Аутлуком. ... Затем, говорю я, что один файл — моя личная переписка, а второй — рабочая. Роли разные. Рабочую я могу передать вместе с работой, а личную понесу дальше.
Если расселить котлеты и мух по разным почтовым ящикам — задача решается элементарно, нет? И, даже если автономной работы не требуется, зачем возиться с RDP при наличии POP/IMAP?
SV.> Посчитайте TCO.
Вот этот пункт будет вообще не в пользу облака (disclaimer: для персонального использования).
Во-первых, при реально массовом обслуживании выиграть за счёт железа нереально — общая вычислительная способность железяк в кармане и зала со шкафами скажем так, несопоставимы.
Во-вторых, у смартов нет тонн накладных расходов на персонал,климатические системы, сертификацию, пожарную безопасность и прочая прочая прочая.
В-третьих, облака падают реже, но, если уж падают — плохо всем.
В-четвёртых, помимо оплаты за интернет, появятся адресные выплаты за сервисы (а сползти будет уже не так просто).
Я ещё долго могу продолжать, пойнт один: для конечных пользователей нет никакой весомой выгоды от тонких клиентов.
SV.> Наконец, подумайте о тех соблазных, которых вы еще не видели. Вот пока я писал это сообщение, пару раз FireFox закрылся, подозреваю, что выкидывал окошко с предложением обновиться, а я продолжал печатать и нажимал что-нибудь не то.
Ок, вместо окошка ушёл бы в ребут инстанс на сервере — что мы выиграли?
SV.> А если бы вся эта память — этакий трепетный конь — хранилась в РБД? Открыл бы я FireFox, а в нем — окошко с формой и моим (потерянным) текстом.
Просто используйте нормальный браузер. Опера обычно восстанавливает состояние полей ввода.
Здравствуйте, SV., Вы писали:
SV.>Еще один прогноз (и рад буду ошибиться): поскольку гадать о будущем интереснее, чем обсуждать конкретные достижения в области серверостроения, а каждый мнит себя визионером, то центр тяжести дискуссии переместится сюда, а про технологию, гребись она конем, все забудут.
Чтобы обсуждение технологии имело смысл, неплохо бы сначала угадать, какую именно технологию обсуждать. А то знаете ли, технологий много, всех обсудить — жизни не хватит
Мой прогноз: в обозримом будующем индустрия будет развиваться в сторону максимально облегченных серверов и сдвига всех возможных вычислений на сторону клиента. При том, что выглядеть это будет так, словно все делается на сервере. Технически это нетривиально, и именно эту технологию мне интересно обсуждать. А не про то, как затолкать традиционный код на сервер.
Здравствуйте, bl-blx, Вы писали:
BB>Так терминальный сервер неплохо оптимизирует процессы клиентов. В частности, страницы BB>исполнимого кода, как и другие страницы "только на чтение", в физической памяти BB>материализуются один раз.
Это заслуга не терминал сервера. По крайней мере в винде.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Гм, а разве я писал про то, что ГУИ задумается на 5 секунд ? Я сказал, что архивация займет 0.5 или 5 — все равно.
Ну ты ж сам начал песнь про то, что:
PD>Суммарное время архивации складывается из
PD>1. Времени манипуляции в UI по выбору диска, каталога и файла(ов) и настроек.
PD>2. Собственно время архивации.
В 10 раз более медленный процесс архивации (при тех же остальных параметрах, ибо иное тобой не оговорено) это просто за пределами разумности.
Следовательно все замедления относим на гуй, раз ты его зачем то упомянул.
PD>Кстати, поманипулируй Compression Method — и получишь эту разницу на одном и том же файле.
Если я жму файл то это значит что мне нужен минимальный его размер. Поэтому кроме Best + Solid другие варианты попросту не рассматриваем.
Ну и да, мне не всё равно 5 сек или 0.5. Если у меня есть к примеру два архиватора, жмут они в абсолютно одинаковый размер но один делает это за 0.5 сек а другой за 5 сек то слоупок улетит в помоечку, где ему самое место.
Рассмотрим масштабируемый высоконагруженный сервер, работающий со множеством клиентов. Пул потоков, потоки обрабатывают юзерские запросы, код абсолютно stateless, все данные юзера хранятся в расшаренной РБД. Профит такой модели — во-первых, надежность: падение отдельного потока не приводит к потере данных, интерфейс РБД предполагает транзакционность. Во-вторых — "гербалайф с таймшером": в каждый момент времени только один из N юзеров парит сервер запросом, а значит утилизация мощности происходит в N раз эффективнее, чем при индивидуальной работе. Разумеется, запросы на ресурсоемкую обработку данных нежелательны, т.к. один такой запрос может сожрать все ресурсы сервера, а желательно, наоборот, кеширование, индексирование и прочие вещи, которые позволят отстреливаться от клиента как можно быстрее. Это была трепетную лань.
Теперь рассмотрим коня, то есть классическое десктопное приложение, например, декомпрессор типа WinRAR'а. Все в памяти, если используются классы — в них полно член-данных, юзер работает с интерфейсом непрерывно, а уж если "делает запрос", то отжирает кучу ресурсов в ходе процесса. Профит такой модели — ну, надо ведь и такие "жоркие" задачи где-то решать, это раз. Два — программировать state-классы привычнее для многих. Три — это еще и сравнительно эффективно, т.к. при явном "фокусе" некоторого процесса есть все шансы, что его виртуальная память маппится на оперативную.
Вопрос, который меня интересует — есть ли какие-то наработки по конвергенции этих двух моделей? Статьи, библиотеки, проекты и так далее. Допустим, есть ультратонкие клиенты, которым надо обрабатывать документы. А они их даже у себя хранить не хотят. Писать алгоритм обработки на T-SQL в таких случаях не вдохновляет, а часто вообще есть код приложения для толстых клиентов, который хотелось бы развивать синхронно. Как люди выкручиваются?
P.S. Кассандрствую: лет через 10 этот вопрос приобретет острейшую актуальность.
Здравствуйте, SV., Вы писали:
SV.>Вопрос, который меня интересует — есть ли какие-то наработки по конвергенции этих двух моделей? Статьи, библиотеки, проекты и так далее. Допустим, есть ультратонкие клиенты, которым надо обрабатывать документы. А они их даже у себя хранить не хотят. Писать алгоритм обработки на T-SQL в таких случаях не вдохновляет, а часто вообще есть код приложения для толстых клиентов, который хотелось бы развивать синхронно. Как люди выкручиваются?
Например, для ультратонких клиентов они запускают толстое, ресурсоемкое
приложение на терминальных серверах.
Здравствуйте, adontz, Вы писали:
A>Задачи должны быть однотипными и примерно одного размера, что бы для любого достаточно большого N, можно было сказать что N одновременно выполняющихся задач создают одинаковую нагрузку вне зависимости от количества экземпляров и планировщик был свободен в выборе. A>Задачи должны быть мелкими и примерно одного размера, чтобы обеспечить приемлемое время отклика и не вызывать голодания. A>Если условия не выполняются, особо не распараллелишь.
A>Ещё один важный момент — объём контекста задачи и его уникальность. Известный факт, выключение HyperThreading может заметно повысить производительность SQL Server, так как ядра перестают перетирать общий кеш. WinRAR читает данные с диска и пишет туда же. Если архивировать в сто потоков, скорость только упадёт, так как головка винчестера будет конвульсивно дёргаться, а не читать или писать данные. Какие-то задачи лучше не распараллеливать.
Так ли важна параллельность? Допустим, запрос сильно озадачивает сервер. В рамках "серверной" модели всегда можно следующий запрос отдать другому серверу.
Сначала хотелось бы просто понять модель, по которой можно перенести классический десктопный софт на сервер. А для этого — посмотреть на то, что уже достигнуто в этом направлении.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Интерфес winrar, в общем, каким был, таким и остался, и ничего тут нового и не нужно. Не в нем задача. И будет он архивировать за 0.5 сек или 5 сек — в общем, не так уж важно.
Фигасе заявы!
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, bl-blx, Вы писали:
BB>>Например, для ультратонких клиентов они запускают толстое, ресурсоемкое BB>>приложение на терминальных серверах.
SV.>Да, это решение, но слишком лобовое. На каждого клиента по экземпляру процесса — где же выгода от централизации?
Так терминальный сервер неплохо оптимизирует процессы клиентов. В частности, страницы
исполнимого кода, как и другие страницы "только на чтение", в физической памяти
материализуются один раз.
Выгоды от централизации (какие мне навскидку видятся в полусонном состоянии ), следующие:
— прямой, несетевой доступ к файловой системе — состояние можно хранить в
простых и быстрых ISAM базах или файлах, использовать блокировки/кэширование на уровне ОС;
— единая цель для деплоймента;
— единая точка защиты фаерволом и антивирусом;
— возможность для пользователя продолжать сессию с любого рабочего места.
Да и, с другой стороны, кто лучше самой ОС может ресурсами управлять с наименьшими
затратами?
Здравствуйте, bl-blx, Вы писали:
BB>>>Например, для ультратонких клиентов они запускают толстое, ресурсоемкое BB>>>приложение на терминальных серверах.
SV.>>Да, это решение, но слишком лобовое. На каждого клиента по экземпляру процесса — где же выгода от централизации?
BB>Так терминальный сервер неплохо оптимизирует процессы клиентов. В частности, страницы BB>исполнимого кода, как и другие страницы "только на чтение", в физической памяти BB>материализуются один раз.
Задам вопрос, который надо было задать сразу: что такое терминальный сервер? Википедия вообще говорит, что это девайс для связки в сеть других девайсов с RS-интерфейсом, не путать с терминальными сервисами и ремотным доступом. Не могли бы вы перечислить все известные вам терминальные серверы, чтобы я понял, что вы имеете в виду? Является ли т.с. соответствующая подсистема винсервера, дающая ремотный десктоп?
Наконец, если является, то о какой оптимизации речь? http://msdn.microsoft.com/en-us/library/aa366785%28v=vs.85%29.aspx — вот этот механизм? Ну да, но этого, по-моему, недостаточно, поскольку типовое приложение проинициализирует множество объектов, которые, хотя и могли бы быть расшарены, будут помещены на незащищенные страницы и, соответственно, продублированы.
BB>Выгоды от централизации (какие мне навскидку видятся в полусонном состоянии ), следующие: BB>- прямой, несетевой доступ к файловой системе — состояние можно хранить в BB>простых и быстрых ISAM базах или файлах, использовать блокировки/кэширование на уровне ОС; BB>- единая цель для деплоймента; BB>- единая точка защиты фаерволом и антивирусом; BB>- возможность для пользователя продолжать сессию с любого рабочего места.
Это понятно, собственно, это и есть мотив изучать сабж. Конечно, формально это будет хоть на три копейки, но оптимальнее, чем запуск приложений на разных машинах — страницы кода расшарятся. Но вот именно, что формально и на три копейки — если сравнить размер бинарей процесса и размер виртуальной памяти, которую он жрет, последний многократно превосходит первый.
Я же имел в виду максимально возможную оптимизацию, см. выше. Которая должна обеспечиваться или методологией разработки подобного софта, или хитрой операционкой, заточенной под удаленный доступ, которая разруливает такие ситуации. Нельзя забывать и о том, что обратная сторона дублирования — повышение надежности, т.к. ошибка в коде, произошедшая в одной сессии не уронит другие сессии. Тут есть о чем подумать, но прежде, чем думать, хотелось бы узнать, что придумано до нас.
Если вы приведете примеры т.с., можно будет покопать каждый и чего-нибудь найти по теме.
Здравствуйте, Pzz, Вы писали:
SV.>>P.S. Кассандрствую: лет через 10 этот вопрос приобретет острейшую актуальность.
Pzz>Через 10 лет у каждого в кармане будет столько CPU power, что разумным будет подход все вычисления туда и сдвинуть, оставив серверу хранение/синхронизацию/обмен данными.
Не сомневаюсь, что у вас так и будет. Но подумайте о пользователях. Я — не самый из них тупой, и CPU power в моем кармане достаточно, но я не осилил такой задачи, как репликация (на мелкософтном языке — синхронизация) данных между двумя .pst-файлами из большого Аутлука и карманным Аутлуком. Когда спрашиваю знатоков, те делают большие глаза: зачем тебе это? Затем, говорю я, что один файл — моя личная переписка, а второй — рабочая. Роли разные. Рабочую я могу передать вместе с работой, а личную понесу дальше. В ответ хмыкают и пожимают плечами. В конце концов ActiveSync заменили на WMDC, WM приговорили, я плюнул и начал ходить в большой Аутлук через RDC, иногда даже — при помощи карманного CPU power. Или спросите поклонников GMail, почему они, несмотря на море CPU power в своем макбуке, делятся секретами с Корпорацией-Злом. Посчитайте TCO. Наконец, подумайте о тех соблазных, которых вы еще не видели. Вот пока я писал это сообщение, пару раз FireFox закрылся, подозреваю, что выкидывал окошко с предложением обновиться, а я продолжал печатать и нажимал что-нибудь не то. А если бы вся эта память — этакий трепетный конь — хранилась в РБД? Открыл бы я FireFox, а в нем — окошко с формой и моим (потерянным) текстом. И это только если одну минуту подумать.
На самом деле, никого убеждать не хочу. Мне бы с техникой разобраться.
Здравствуйте, Banned by IT, Вы писали:
BBI>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Интерфес winrar, в общем, каким был, таким и остался, и ничего тут нового и не нужно. Не в нем задача. И будет он архивировать за 0.5 сек или 5 сек — в общем, не так уж важно. BBI>Фигасе заявы!
А поконкретнее можно ? Суммарное время архивации складывается из
1. Времени манипуляции в UI по выбору диска, каталога и файла(ов) и настроек.
2. Собственно время архивации.
Ну и как ? За 0.5 сек сумеешь выбрать файлы, установить , куда записывать архив, ну там еще пароль и опции поменять ?
Еще один прогноз (и рад буду ошибиться): поскольку гадать о будущем интереснее, чем обсуждать конкретные достижения в области серверостроения, а каждый мнит себя визионером, то центр тяжести дискуссии переместится сюда, а про технологию, гребись она конем, все забудут.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и как ? За 0.5 сек сумеешь выбрать файлы, установить , куда записывать архив, ну там еще пароль и опции поменять ?
У мелкософта есть 2 константы, которые в разных местах используются, как "предел терпения" пользователя: 5 и 10 секунд. Это несмотря на то, что перед тем пользователь долго елозил мышью.
5 секунд ждать, ничего не делая, действительно утомительно. С ритма сбивает, знаете ли
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ну и как ? За 0.5 сек сумеешь выбрать файлы, установить , куда записывать архив, ну там еще пароль и опции поменять ?
Pzz>У мелкософта есть 2 константы, которые в разных местах используются, как "предел терпения" пользователя: 5 и 10 секунд. Это несмотря на то, что перед тем пользователь долго елозил мышью.
Pzz>5 секунд ждать, ничего не делая, действительно утомительно. С ритма сбивает, знаете ли
Ты о чем ? Архив приличных размеров winrar делает десяток минут, а то и больше.
Здравствуйте, Pavel Dvorkin, Вы писали:
Pzz>>5 секунд ждать, ничего не делая, действительно утомительно. С ритма сбивает, знаете ли
PD>Ты о чем ? Архив приличных размеров winrar делает десяток минут, а то и больше.
Я лишь оспариваю твой тезис, что нет разницы, 0.5 секунды или 5. А с тем, что бывают программы, которым по долгу службы приходится хорошенько задуматься я оспаривать, естественно, не собираюсь
Здравствуйте, Pzz, Вы писали:
Pzz>Я лишь оспариваю твой тезис, что нет разницы, 0.5 секунды или 5. А с тем, что бывают программы, которым по долгу службы приходится хорошенько задуматься я оспаривать, естественно, не собираюсь
И это я тоже не понял (в применении к winrar). Все равно на полный процесс архивации уйдет минимум секунд 20 (выбор файла, каталога для записи архива и т.д.)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Интерфес winrar, в общем, каким был, таким и остался, и ничего тут нового и не нужно. Не в нем задача. И будет он архивировать за 0.5 сек или 5 сек — в общем, не так уж важно. BBI>>Фигасе заявы!
PD>А поконкретнее можно ? Суммарное время архивации складывается из
PD>1. Времени манипуляции в UI по выбору диска, каталога и файла(ов) и настроек. PD>2. Собственно время архивации.
PD>Ну и как ? За 0.5 сек сумеешь выбрать файлы, установить , куда записывать архив, ну там еще пароль и опции поменять ?
Ты не поверишь, но у меня типичный use case примерно секунда и выходит.
Уже создан профиль с настройками, выбран по умолчанию.
WinRAR запускается сразу в том каталоге, где лежат файлы. Причём интерфейс появляется мгновенно, ожидание тут будет крайне неприятно.
А дальше выбор файлов (в 99% случаев это Ctrl-A, остальной 1% — тыц мышой в единственный файл), потом Alt-A и Enter. По завершению — дроп архива мышой из WinRAR в уже открытый шаблон письма в почтовике.
Поскольку довольно часто приходилось отправлять свежесобранное мылом то процесс упаковки билда доведён почти до автоматизма.
И если вдруг гуй задумается на 5 секунд это будет epic fail.
Здравствуйте, SV., Вы писали:
SV.>Или спросите поклонников GMail
Что понимать под поклонниками? Вот у меня несколько личных ящиков на gmail, я поклонник али как?
SV.> почему они, несмотря на море CPU power в своем макбуке
макбук и gmail как то немного не совместимы по идеологии, не? В случае "поклонников".
SV.> делятся секретами с Корпорацией-Злом.
Ну как бы трудно не делиться почтой с почтовым сервером. В любом случае вся почта проходит через него. Или ты о чём то другом?
Здравствуйте, Banned by IT, Вы писали:
PD>>Ну и как ? За 0.5 сек сумеешь выбрать файлы, установить , куда записывать архив, ну там еще пароль и опции поменять ? BBI>Ты не поверишь, но у меня типичный use case примерно секунда и выходит. BBI>Уже создан профиль с настройками, выбран по умолчанию. BBI>WinRAR запускается сразу в том каталоге, где лежат файлы. Причём интерфейс появляется мгновенно, ожидание тут будет крайне неприятно. BBI>А дальше выбор файлов (в 99% случаев это Ctrl-A, остальной 1% — тыц мышой в единственный файл), потом Alt-A и Enter. По завершению — дроп архива мышой из WinRAR в уже открытый шаблон письма в почтовике. BBI>Поскольку довольно часто приходилось отправлять свежесобранное мылом то процесс упаковки билда доведён почти до автоматизма. BBI>И если вдруг гуй задумается на 5 секунд это будет epic fail.
Гм, а разве я писал про то, что ГУИ задумается на 5 секунд ? Я сказал, что архивация займет 0.5 или 5 — все равно. Кстати, поманипулируй Compression Method — и получишь эту разницу на одном и том же файле.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И это я тоже не понял (в применении к winrar). Все равно на полный процесс архивации уйдет минимум секунд 20 (выбор файла, каталога для записи архива и т.д.)
Пауза в 5 сек очень раздражает. Даже если перед тем 20 сек. мышой тыкал.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>И это я тоже не понял (в применении к winrar). Все равно на полный процесс архивации уйдет минимум секунд 20 (выбор файла, каталога для записи архива и т.д.)
Pzz>Пауза в 5 сек очень раздражает. Даже если перед тем 20 сек. мышой тыкал.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Pavel Dvorkin, Вы писали:
Pzz>>>Пауза в 5 сек очень раздражает. Даже если перед тем 20 сек. мышой тыкал.
PD>>А пауза в час ?
Pzz>К паузе в час можно подготовиться. Например, запланировать рабочее совещание или заказать столик в ресторане
Что-то я тебя совсем понимать перестал. Или ты меня. Давай закончим.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, bl-blx, Вы писали:
SV.>Задам вопрос, который надо было задать сразу: что такое терминальный сервер? Википедия вообще говорит, что это девайс для связки в сеть других девайсов с RS-интерфейсом, не путать с терминальными сервисами и ремотным доступом. Не могли бы вы перечислить все известные вам терминальные серверы, чтобы я понял, что вы имеете в виду? Является ли т.с. соответствующая подсистема винсервера, дающая ремотный десктоп?
Да, под терминальным сервером я имел в виду Windows Terminal Services. Ремотный десктоп,
насколько я знаю, построен на урезанном ядре WTS. Туда же добавил бы Citrix Metaframe.
Также я подразумевал и X-Windows (X11), хотя там несколько иной подход.
