Здравствуйте, Cyberax, Вы писали:

S>>Только в случае, если пропускная способность очень низкая, ну просто совсем. В остальных скорость и удобство будут выше.
C>Нет, не будут. Запусти сервер в Австралии (на Amazon AWS) с Windows и сам попробуй посмотреть.
Не хочу — аккаунт на AWS у меня в суспенде. Локально сделал канал 1Mbit/s — примерно одинаково (Powershell дольше возвращает результаты, т.к. данных больше идёт). Если выставить на канале потери 40% — ssh работает лучше, соглашусь.
А вот при широком канале и лаге 1000мс, Powershell долго думает над автодополнением (зато потом быстро переключает варианты) и не тормозит при вводе, а вот ssh тупит над каждым нажатием — как и ожидалось.

C>>>Нету у SSH такого "принципа".
S>>т.е. эмуляция терминала через ssh внезапно не так работает? У вас тупой терминал в ssh: вы нажали кнопку, символ ушёл по сети (возможно после переваривания алгоритмом Нейгла), вам пришёл пакет с ответом — все операции, кроме возврата потока данных проходят с задержкой.
C>И что? Я сразу набираю всю строку.
Поздравляю

C>Да, и про mosh как-то пропустил: https://youtu.be/XsIxNYl0oyU?t=374
Выглядит неплохо.

C>>>Я обычно сразу набираю что-нибудь типа "cd /v/l/t/", жму tab и оно разворачивается в "cd /var/log/tomcat" причём полностью асинхронно. И пока оно разворачивается, я могу писать уже следующую команду.
S>>Ну, во-первый, вы сейчас как раз о рутинных действиях говорите (которые легко автоматизируются). Если вам нужно знать результаты предыдущей команды, если вы не знаете точно где лежит файл — ничего близкого по скорости у вас не выйдет.
C>Выйдет, я просто файл из предидущей команды буду использовать в следующей. Ну или подожду эти 500 миллисекунд на RTT в конце набора команды.
Ну выйдет так выйдет.


C>А вот мышкой надо ждать ответа от КАЖДОГО атома действия.
Протестил сейчас с лагом 200-250 мс — работать вполне можно. На более высоких будут проблемы. Но более высокий — это в основном Австралия.

C>>>И откуда он берёт, например, список веток в git'е?
S>>С удалённой системы. Запрос на параметры команды отправляется отдельно.
C>И как-то магически без сетевой задержки? И для того же git'а потребуется 3-4 раундтрипа при удалённом исполнении, тогда как на показ отрендеренного текста достаточно 1 RTT.
С сетевой задержкой. Просто автодополнение получит сразу все варианты для текущего контекста, и повторный запрос будет только при его смене.

C>>>То-то там настроек примерно легион. И найти нужную — это надо знать путь из кликов.
S>>Да. А cli-команды вам во сне являются, их знать не нужно.
C>В CLI они доступны все сразу, без долгого перещёлкивания по контекстным панелям.
То есть всё-таки во сне явились.

C>Неа, тут всё просто. Vim и less — интерактивные утилиты. Их можно использовать асинхронно.
C>А вот MC — уже GUI, так как требует синхронных действий.
...интерактивные утилиты... А вот MC — уже GUI...
1) двойные стандарты такие двойные
2) Как вы LESS собирайтесь использовать "асинхронно"? Поиск, к примеру, "асинхронный", прокрутку строк "асинхронную"? Про vim, вобщем-то тоже самое.

C>>>См. профессиональные комплекты восстановления.
S>>Смотрел. Работал. И что? Они, кстати, обычно GUI'шные.
C>Не смотрел, значит.
Ну да, вам виднее. Кстати, получается те которые я видел непрофессиональные, потому что там есть GUI. Симптоматично.

C>Тут картинку уже постили, про кривляния виндузятников.
Только эта картинка больше показывает внутренний мир линуксодов: как они видят окружающую действительность. И знаете — эмпирически совпадает, даже на вас видно.

Здравствуйте, Cyberax, Вы писали:

S>>Только в случае, если пропускная способность очень низкая, ну просто совсем. В остальных скорость и удобство будут выше.
C>Нет, не будут. Запусти сервер в Австралии (на Amazon AWS) с Windows и сам попробуй посмотреть.
Не хочу — аккаунт на AWS у меня в суспенде. Локально сделал канал 1Mbit/s — примерно одинаково (Powershell дольше возвращает результаты, т.к. данных больше идёт). Если выставить на канале потери 40% — ssh работает лучше, соглашусь.
А вот при широком канале и лаге 1000мс, Powershell долго думает над автодополнением (зато потом быстро переключает варианты) и не тормозит при вводе, а вот ssh тупит над каждым нажатием — как и ожидалось.

C>>>Нету у SSH такого "принципа".
S>>т.е. эмуляция терминала через ssh внезапно не так работает? У вас тупой терминал в ssh: вы нажали кнопку, символ ушёл по сети (возможно после переваривания алгоритмом Нейгла), вам пришёл пакет с ответом — все операции, кроме возврата потока данных проходят с задержкой.
C>И что? Я сразу набираю всю строку.
Поздравляю

C>Да, и про mosh как-то пропустил: https://youtu.be/XsIxNYl0oyU?t=374
Выглядит неплохо.

C>>>Я обычно сразу набираю что-нибудь типа "cd /v/l/t/", жму tab и оно разворачивается в "cd /var/log/tomcat" причём полностью асинхронно. И пока оно разворачивается, я могу писать уже следующую команду.
S>>Ну, во-первый, вы сейчас как раз о рутинных действиях говорите (которые легко автоматизируются). Если вам нужно знать результаты предыдущей команды, если вы не знаете точно где лежит файл — ничего близкого по скорости у вас не выйдет.
C>Выйдет, я просто файл из предидущей команды буду использовать в следующей. Ну или подожду эти 500 миллисекунд на RTT в конце набора команды.
Ну выйдет так выйдет.


C>А вот мышкой надо ждать ответа от КАЖДОГО атома действия.
Протестил сейчас с лагом 200-250 мс — работать вполне можно. На более высоких будут проблемы. Но более высокий — это в основном Австралия.

C>>>И откуда он берёт, например, список веток в git'е?
S>>С удалённой системы. Запрос на параметры команды отправляется отдельно.
C>И как-то магически без сетевой задержки? И для того же git'а потребуется 3-4 раундтрипа при удалённом исполнении, тогда как на показ отрендеренного текста достаточно 1 RTT.
С сетевой задержкой. Просто автодополнение получит сразу все варианты для текущего контекста, и повторный запрос будет только при его смене.

C>>>То-то там настроек примерно легион. И найти нужную — это надо знать путь из кликов.
S>>Да. А cli-команды вам во сне являются, их знать не нужно.
C>В CLI они доступны все сразу, без долгого перещёлкивания по контекстным панелям.
Вообще не факт. CLI есть не только линуксовое, но даже в линуксе при использовании интерактивных утилит контекст меняется, и не все команды доступны во всех контекстах. Так что что и где жать надо в любом случае.

C>Неа, тут всё просто. Vim и less — интерактивные утилиты. Их можно использовать асинхронно.
C>А вот MC — уже GUI, так как требует синхронных действий.
...интерактивные утилиты... А вот MC — уже GUI...
1) двойные стандарты такие двойные
2) Как вы LESS собирайтесь использовать "асинхронно"? Поиск, к примеру, "асинхронный", прокрутку строк "асинхронную"? Про vim, вобщем-то тоже самое.

C>>>См. профессиональные комплекты восстановления.
S>>Смотрел. Работал. И что? Они, кстати, обычно GUI'шные.
C>Не смотрел, значит.
Ну да, вам виднее. Кстати, получается те которые я видел непрофессиональные, потому что там есть GUI. Симптоматично.

C>Тут картинку уже постили, про кривляния виндузятников.
Только эта картинка больше показывает внутренний мир линуксодов: как они видят окружающую действительность. И знаете — эмпирически совпадает, даже на вас видно.