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

Полет из Сиэтла в Москву/Киев – это 15-17 часов лету и минимум одна пересадка. Это если билеты хорошие. Если вам нужно не в Москву/Киев, то прибавьте еще несколько часов и геморрой с получением багажа, пересадкой в другой терминал/аэропорт. Или поезд (мой случай). Уже после этого чемоданы хочется выбросить и никогда больше не видеть.

Теперь вспомним, что на руках есть еще и ребенок. Или два. Кто с детьми не ездил, тот не поймет. Хотя мне еще предстоит первая поездка с двумя сорванцами. Заранее мысленно содрогаюсь. Некоторые вообще едут в одиночку с двумя. Героические, бесстрашные люди. Хотя может быть это не так уж и страшно. Тем не менее, багаж не становится от этого более любимым.

Далее – таможня. В Москве/Киеве это уже не проблема, а вот в Чопе еще не так давно докапывались до количества мобильников на пассажирскую душу, не иначе как с целью убедить особо сговорчивых поделиться дензнаками. Методы борьбы с ними известны, но вы думаете, что кому-то хочется общаться с этими милыми людьми? Я уже не говорю о прочих мелочах, вроде заботы о сохранности посылки, потерянном багаже и прочих прелестях, ожидающих путешественника.

Ну и как вы думаете, оно мне надо?

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

1. Клиент посылает текущее время вместе с пакетом:

   message->timestamp = (DWORD)QueryPerformanceCounter();
   send(message);
   

2. Сервер прибавляет свое время при приеме пакета и отнимает – при посылке:

   message->timestamp += (DWORD)QueryPerformanceCounter();
   …
   message->timestamp -= (DWORD)QueryPerformanceCounter();
   send(message);

3. Клиент сравнивает текущее время с полученным в пакете:

   DWORD delta = (DWORD)QueryPerformanceCounter() - message->timestamp;
   double latency = (double)delta / QueryPerformanceFrequency();

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

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

Подпись к картинке написана на датском (Update: уже переписали по-английски): «у Ноя были проблемы с полноценным ночным сном». Моего уровня датского как раз хватает на чтение таких простых предложений. Однако почему именно датский?

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

Фирмы непродвинутые пытаются создавать девайсы для какой-то заранее определённой цели. Как правило, они пытаются угадать «желания потребителей». Получается это у них по-разному, но, как правило, плохо. Большая часть функций, встроенных в их девайсы, обычно бывает невостребована, пользователи капризничают и плюются, на одну кисленькую удачу приходится десять неудач и так далее.

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

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

Дальше так. Пользователи видят няшку и покупают – из тех же соображений, из которых покупают котят и кристаллы Сваровски: «ой, красивенькое». Потом выясняется, что купили фигню, но выкинуть её жалко, потому что фигня недешёвая.

Значит что? Значит, нужно НАЙТИ ЕЙ ПРИМЕНЕНИЕ.

Мудрый Стив Джобс знает, что люди не столь глупы, сколь ленивы. Думать-то они умеют, просто не любят. Но если уж начинают думать, они, глядишь, и колесо, и порох изобретут, и до рыбной запеканки додумаются. А уж применение красивой удобной штучке – тем более отыщут. Чай, не бином.
…

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

Источник: http://krylov.livejournal.com/1977173.html

Консоль в Unix

Посимвольный ввод и вывод через stdin/stdout – единственный канал общения с консолью (терминалом), доступный приложению. Терминалом, при этом, может быть все что угодно – файл на диске, виртуальный терминал в X Window, труба (pipe) из другого приложения и т.д. Между терминалом и приложением передается текст. Нажатия нетекстовых клавиш (клавиш управления курсором, функциональных клавиш и т.п.) транслируются терминалом в управляющие последовательности/ESC коды (см. Ecma-35). С помощью аналогичных управляющих последовательностей приложение может посылать терминалу команды вроде «перейти на следующую строку».

Собственно говоря, полностью корректная отработка ESC кодов, – это весьма сложная задача ввиду сильнейшего разнообразия различных видов терминалов. Библиотека ncurses, к примеру, содержит описания более чем полутора тысяч разных терминальных конфигураций. Неразберихи добавляет и необходимость согласования кодировок текста, которым обмениваются терминал и приложение. К счастью, и разнообразие терминалов, и разнообразие кодировок постепенно сходит на нет – «железные» терминалы почти вымерли; Unicode шагает по планете.

Архитектура консольной подсистемы в Windows во многом отличается от Unix:

Консоль в Windows

Вместо символьного ввода-вывода, приложение общается с консолью через вызовы удаленных функций (RPC). Клавиатурный ввод передается в виде последовательности нажатий клавиш, а не в виде последовательности символов, полученной в результате нажатия этих клавиш. В результате в Windows приложение может, например, отличить Ctrl+Shift+Left от Shift+Left. С другой стороны, в Windows приложение обязано знать тип и раскладку клавиатуры, выбранные в терминале, что в случае удаленного терминала превращается в проблему.

Для приложений, которым не интересны подробности нажатий клавиш, нажатия клавиш транслируется в традиционный символьный ввод-вывод. К примеру, ReadConsole глубоко внутри вызывает ReadConsoleInput. На Unix приходится решать обратную задачу – из потока символов выделять нажатия клавиш.

Стандартный ввод-вывод отделен от собственно консоли. В результате, перенаправление стандартного ввода-вывода не перехватывает весь консольный ввод-вывод. Попробуйте на досуге перенаправить вывод Far Manager в файл. А затем посмотрите, что получится если сделать то же самое с Midnight Commander.

Продолжение, надеюсь, следует…

shaf :

Тогда запости вид из окна

Не из окна, правда, с крыльца, но вид (по клику открывается в полном размере):

Вид с крыльца

PS. Никак не могу попать домой днем…