Комментарии 91
Браво! Замечательная статья! Читается лучше иной художки!
Интересная статья, но маловато технических подробностей конкретно вашей реализации эмулятора терминала(а не пишущих машинок вообще).
Кстати, название ncurses — библиотеки для рендеринга изображения с использованием esc-кодов, вообще говоря, идёт от английского to curse — высказывать благодарность за удобную и понятную вещь.Вот это красиво завернуто :)
>сражавшийся с бездной легаси, си и longjump'ов в коде
Примерно так ад программистов я себе и представлял, да.
Примерно так ад программистов я себе и представлял, да.
>>Потом, когда писали линукс, …
>>Тем же путём, кстати, пошёл UNUX и его клоны: solaris, FreeBSD, hp-ux и т.д.
Вообще-то это линукс пошел по пути UNIX. Вы путатете яйца с курицей =)
>>Тем же путём, кстати, пошёл UNUX и его клоны: solaris, FreeBSD, hp-ux и т.д.
Вообще-то это линукс пошел по пути UNIX. Вы путатете яйца с курицей =)
Поправьте эпиграф
Если посадить тысячу мартышек на за тысячу пишущих машинок…
Если посадить тысячу мартышек на за тысячу пишущих машинок…
Мой друг когда-то пытался написать терминалку и интересуется, поддерживает ли ваша радость символы занимающие два и более знакомест (CJK иероглифы и прочее)?
с большой вероятностью нет, т.к. мы юникод поддерживаем в смысле «не режем посредине многобайтного символа». Все операции, связанные с выводом комбинированных или нестандартных по расположению знаков мы просто не делаем, т.к. не разбираемся в содержимом юникода.
Если возникнет проблема — сделаем.
Если возникнет проблема — сделаем.
Речь об этом?
Да.
Попробуйте создать несколько файлов именами из «нихонги» и открыть эту директорию в mc.
У mc должны поехать рамки.
Попробуйте создать несколько файлов именами из «нихонги» и открыть эту директорию в mc.
У mc должны поехать рамки.
От иероглифов с большой вероятностью не полезет (консоль использует моноширинные и только моноширинные глифы), а вот от комбинированных символов — да (когда глиф на экране формируется несколькими символами). Но поддержка подобных символов потребует, чтобы библиотека, отрабатывающая команды, знала что-то вообще о том, что за символ ей скормили — а это отдельный сложный мир.
Иероглифы традиционно занимают 2 знакоместа, комбинирующие символы (и всякие null-width space) — 0 знакомест. В любом случае нужно знать ширину символа.
Вообще, одно, насколько я с ними работал. Просто при их использовании остальные шрифты рисуются более крупно или с большими отступами.
Тут видно, что 本 ровно в 2 раза шире, чем остальные буквы.
Впрочем, половина старого *curses-софта даже при поддержке терминалом широких символов всё равно неправильно считает ширину.
Впрочем, половина старого *curses-софта даже при поддержке терминалом широких символов всё равно неправильно считает ширину.
с какой стати то?
У меня тоже было желание написать свою терминалку с мышью и спрайтовой анимацией (что-то вроде расширенной псевдографики). Причем хотелось разработать терминальный интерфейс, совместимый с VTxxx на основе UTF-8 кодирования символов.
Идея такая: каждый спрайт представляет собой монохромное или цветное изображение (в том числе и анимированное и с поддержкой маски прозрачности для прорисовки нескольких «слоев»), занимающее на экране одно или несколько соседних знакомест.
Спрайт в потоке данных кодируется как обычный символ, кодом из UTF-8, и перед первым его использованием загружается его bitmap-образ (который представляет собой hex-последовательность символов, разделенных символом \х08 (BackSpace), для того чтобы, «старые» терминалы, не готовые к такому сценарию не выводили всякий «мусор» на экран).
Технически можно продумать вариант использования GIF-формата в качестве способа представления спрайта.
Набор загружаемых спрайтов фактически является «цветным растровым шрифтом».
Идея загрузки «шрифта» была позаимствована у матричных принтеров Epson.
Таким образом спрайты позволят на порядок расширить возможности ASCII-ART'а и псевдографики.
О готовности обмена спрайтами (в том числе и о размерах матрицы знакоместа) терминальный сервер и терминальный клиент могут «договориться» с помощью протокола TELNET.
Хотелось сделать поддержку работы терминала в полноэкранном графическом режиме.
Оставалось только продумать, как кодировать перемещение мыши.
Кстати, в старые-добрые времена, некоторые DOS-программы, работавшие полностью в текстовом режиме (например Нортон-утилиты) умели очень хитро делать эмуляцию CGA-курсора мыши в виде стрелки.
А, кодирование Unicode, позволило бы использовать и иероглифы в терминалке.
Идея такая: каждый спрайт представляет собой монохромное или цветное изображение (в том числе и анимированное и с поддержкой маски прозрачности для прорисовки нескольких «слоев»), занимающее на экране одно или несколько соседних знакомест.
Спрайт в потоке данных кодируется как обычный символ, кодом из UTF-8, и перед первым его использованием загружается его bitmap-образ (который представляет собой hex-последовательность символов, разделенных символом \х08 (BackSpace), для того чтобы, «старые» терминалы, не готовые к такому сценарию не выводили всякий «мусор» на экран).
Технически можно продумать вариант использования GIF-формата в качестве способа представления спрайта.
Набор загружаемых спрайтов фактически является «цветным растровым шрифтом».
Идея загрузки «шрифта» была позаимствована у матричных принтеров Epson.
Таким образом спрайты позволят на порядок расширить возможности ASCII-ART'а и псевдографики.
О готовности обмена спрайтами (в том числе и о размерах матрицы знакоместа) терминальный сервер и терминальный клиент могут «договориться» с помощью протокола TELNET.
Хотелось сделать поддержку работы терминала в полноэкранном графическом режиме.
Оставалось только продумать, как кодировать перемещение мыши.
Кстати, в старые-добрые времена, некоторые DOS-программы, работавшие полностью в текстовом режиме (например Нортон-утилиты) умели очень хитро делать эмуляцию CGA-курсора мыши в виде стрелки.
А, кодирование Unicode, позволило бы использовать и иероглифы в терминалке.
Таким образом, вы РИСУЕТЕ ТЕКСТОВУЮ консоль? А зачем!? Почему не отдавать её ниболее естественным образом — по telnet (ssh) и пустьу пользователя все эти коды обрабатываются хоть в PuTTY хоть в xterm хоть где? Зачем удалённый эмулятор консоли вообще нужен?
Т.е. я не очень понимаю use case — нужно видеть консоль виртуальной машины именно из браузера. Как-то мне кажется, что те, кому надо видеть консоль, обладают более адекватными инструментами для наблюдения консоли вместо этих костылей, paste в браузере и война с пониманием браузером клавиатуры.
Ну вот я бы не отказался от терминала в JS, задолбали пользователи «а мы не умеем/боимся». Хотя таких JS-библиотек с десяток и все они лучшие и передовые. Меня тут скорее всего напрягло «Си» и «легаси» одном ряду. Это говорит о принципиальном усложнении ситуации и об ООП головного мозга.
Вот очень даже неплохой терминал на JS
Эти пользователи и в КОНСОЛЬ не лазают. У тебя, впрочем, пользователям консоль и недоступна, что закономерно.
Вот пусть учатся лазать. Как это недоступно? Это ты чего на меня клевещешь? :)) Я как раз известен своей разумной паранойей. Со времён Петерхоста веб-мастеров в консоль гоню.
Щорс, ты меня огорчаешь. Ты тоже путаешь консоль (getty + login — VGA + клавиатура или COM-порт, работает начиная от boot loader'а, а в серверных матерях прямо от BIOS'а, и туда ещё при старте ядра всякое про устройства пишется) и эмуляцию консоли (sshd/telnetd).
В консоль ты пользователей не пускаешь.
И вообще в консоль надо ОЧЕНЬ редко — когда у тебя сервер не грузится из-за косяков в конфигурации ядра или ты в файрволле набагал и тебя не пускают или файловая система не монтируется или при инсталляции sshd забыл разрешить. Короче, пользователям туда не надо, туда надо только руту и в случае дизастера а не для работы.
В консоль ты пользователей не пускаешь.
И вообще в консоль надо ОЧЕНЬ редко — когда у тебя сервер не грузится из-за косяков в конфигурации ядра или ты в файрволле набагал и тебя не пускают или файловая система не монтируется или при инсталляции sshd забыл разрешить. Короче, пользователям туда не надо, туда надо только руту и в случае дизастера а не для работы.
По ssh люди и сами ходить могут. Пока не ломают себе в машине ssh. Собственно, именно для этого консоль и нужна.
Вообще, необходимость делать полноценный эмулятор возникла в основном из-за текстовых редакторов — если нужно поправить файл, то иногда это нужно делать с консоли, а vim, nano и mcedit покрывают, наверное, процентов 95% всех ESC кодов и сложных случаев отрисовки.
Вообще, необходимость делать полноценный эмулятор возникла в основном из-за текстовых редакторов — если нужно поправить файл, то иногда это нужно делать с консоли, а vim, nano и mcedit покрывают, наверное, процентов 95% всех ESC кодов и сложных случаев отрисовки.
Если добавить в полноценный эмулятор вменяемую поддержку мыши, то он станет еще полноценнее)
Мы об этом думали, технически там никаких особых проблем нет. Думаю, если в этом будет какая-то реальная потребность, то можно будет доделать. От библиотеки там почти ничего и не требуется-то, в основном вся нагрузка на JS пойдёт.
Конечно же есть необходимость!
Большинство современных текстовых редакторов используют мышь!
Большинство современных текстовых редакторов используют мышь!
ИМХО там довольно ограниченное взаимодействие. Ну, во-всяком случае, я в консоли gpm обычно не использую.
Блин, тут речь идет не о личных предпочтениях.
Я ж ведь сам могу свой софт написать, который интенсивно использует мышу и захотеть запустить его в облаке.
Я ж ведь сам могу свой софт написать, который интенсивно использует мышу и захотеть запустить его в облаке.
Именно в консоли? Текстовой? Ну, там, куда dmesg выводится? Не эмуляции консоли через sshd/telnetd, а в настоящей, аппаратной консоли (которая, конечно, виртуализируется XEN'ом, но это уже детали)? Мне сложно себе представить такой софт. Приведите пример.
Запускайте, кто ж вам мешает.
JFYI: консоль в зене — последовательный порт. И она может ровно то, что может делать линукс на последовательном порте.
JFYI: консоль в зене — последовательный порт. И она может ровно то, что может делать линукс на последовательном порте.
Обработка javascript'ом всех трёх кнопок мыши + их же с зажатым shift, и это не считая некоторого усложнения кода терминала. Ради нескольких приложений, прекрасно работающих и без мыши. Зачем?
Дык ведь этот велосипедный терминал как раз и изобретается только для поддержки всего лишь нескольких приложений, прекрасно работающих в том числе и с мышью.
Ведь с этими приложениями можно же и так работать например через то же путти.
Ведь с этими приложениями можно же и так работать например через то же путти.
Вы не поняли.
Консоль в ssh. Человек делает «ssh user@consoles.hoster.tld» (обратите внимание — не root@server.of.user.tld), вводит пароль, ему показывают список его [вирутальных] серверов, он выбирает, видит именно КОНСОЛЬ.
Всё что нужно — поставить вместо шелла ему программку, которая будет получать те самые данные которые вы интерпретируете своей библиотекой и отправлять их пользователю как поток байтов.
Зачем браузер, зачем бибилиотека?
Консоль в ssh. Человек делает «ssh user@consoles.hoster.tld» (обратите внимание — не root@server.of.user.tld), вводит пароль, ему показывают список его [вирутальных] серверов, он выбирает, видит именно КОНСОЛЬ.
Всё что нужно — поставить вместо шелла ему программку, которая будет получать те самые данные которые вы интерпретируете своей библиотекой и отправлять их пользователю как поток байтов.
Зачем браузер, зачем бибилиотека?
Думаю, что если бы топикстартер представлял объём работы заранее, он бы так и сделал.
Ну вот мне кажется, что это вообще две разные, малосвязаные между собой, задачи — -дать консоль пользователям и сделать эмулятор терминала в браузере. Можно сначала сделать первое малой кровью, а потом уже развелкаться терминалами на Java/JS в свободное время (кстати, терминал в виде апплета и даже, более того, ssh-клиент в виде апплета я видел много лет назад).
Конечно, потом таким терминалом из браузера можно будет подключаться И К КОНСОЛИ тоже, но, в целом эти две задачи никак не связаны и гораздо лучше их решать по отдельности — получается два законченных решения каждое из которых может работать в связке с другими (на консоль можно ходить любым терминалом, терминалом можно ходить на любые хосты) — а так получается вещь в себе за много денег (человекочасов).
Меня удивляет именно постановка задачи — она мне кажется непродуманной, мягко говоря.
Конечно, потом таким терминалом из браузера можно будет подключаться И К КОНСОЛИ тоже, но, в целом эти две задачи никак не связаны и гораздо лучше их решать по отдельности — получается два законченных решения каждое из которых может работать в связке с другими (на консоль можно ходить любым терминалом, терминалом можно ходить на любые хосты) — а так получается вещь в себе за много денег (человекочасов).
Меня удивляет именно постановка задачи — она мне кажется непродуманной, мягко говоря.
Э… истории не будет. Мы этот вариант прорабатывали. Либо нам нужно писать аналог screen (screeen в данном случае не подходит), либо человек остаётся без вывода до момента подключения.
Всё что нужно — писать в файл всё и скармливать файл при подключении, зачем аналог Screen, зачем хранить картинку? Она быстро-быстро отрисуется при подключении.
Разорвёте esc-код в середине — побъёте картинку. Потенциально — до состояния нечитаемой.
Будете сохранять всё — где ж вы эти десятки и сотни мегабайт хранить будете?
Будете сохранять всё — где ж вы эти десятки и сотни мегабайт хранить будете?
Сотни мегабайт?! Эмм… Я не знаю, как эти ваши линуксы, а FreeBSD хорошо если пару килобайт в день на консоль выводит. Ну будет МЕГАБАЙТ на клиента — ну подарите вы ему этот мегабайт стораджа, проблем-то, он вам за сотни мегабайт платит.
while true;do rmmod ixgbe;modprobe ixgbe;done — и 64к/сек помойки вам обеспечено. (при условии, что у вас не 10Г сетевуха). То же самое может быть от любого модуля ядра.
Я не говорю, что это все делают, я говорю, «что делать будем, если таковой объявится»? Мы в тестах консоли вполне делали hexdump /dev/random'а.
Главная разница провайдера и энтрепрайза, что в энтерпрайзе можно сказать «не делайте так», а провайдер должен быть готов к любому поведению.
Я не говорю, что это все делают, я говорю, «что делать будем, если таковой объявится»? Мы в тестах консоли вполне делали hexdump /dev/random'а.
Главная разница провайдера и энтрепрайза, что в энтерпрайзе можно сказать «не делайте так», а провайдер должен быть готов к любому поведению.
Да, и про историю я ничего не писал, кстати. Когда я подключаюсь к своему физическому серверу по COM-порту в случае если он перестаёт отвечать по сети — у меня нет никакой истории :) Тут ровно та же петрушка. Всё, что вам было нужно — заворачивать виртуальный ком-порт в ssh по требованию (подключению к ssh) — зачем вам была вообще эта эмуляция?
Нет, задача интересная, я бы с удовольствием такое попрограммировал за денежки, мотивацию программиста я хорошо понимаю. Мотивацию бизнеса давать на это деньги — не понимаю.
Кстати, был такой ssh-клиент на винде — telneat, в последствие ShellGuard. И вот он умел эмулировать любой терминал по термкапу. Т.е. он читал termcap и настраивал себя по нему — как делает [n]curses с КЛИЕНТСКОЙ стороны (для вывода), только наоборот. Его исходники болтались в сети, на С/C++, очень аккуратно написан был. Более точной эмуляции, например, FreeBSD'шной cons25 я не видел :) А ему было пофигу кого изображать — он одинаково точно делал хоть vt100 хоть xterm хоть cons25 хоть прямо screen, именно ТОЧНО ИЗОБРАЖАЛ а не просто ставил соотв. переменную TERM (в отличие от того же PuTTY — представится может кем угодно, но реально xterm понимает и всё). Но это уже другая история.
Нет, задача интересная, я бы с удовольствием такое попрограммировал за денежки, мотивацию программиста я хорошо понимаю. Мотивацию бизнеса давать на это деньги — не понимаю.
Кстати, был такой ssh-клиент на винде — telneat, в последствие ShellGuard. И вот он умел эмулировать любой терминал по термкапу. Т.е. он читал termcap и настраивал себя по нему — как делает [n]curses с КЛИЕНТСКОЙ стороны (для вывода), только наоборот. Его исходники болтались в сети, на С/C++, очень аккуратно написан был. Более точной эмуляции, например, FreeBSD'шной cons25 я не видел :) А ему было пофигу кого изображать — он одинаково точно делал хоть vt100 хоть xterm хоть cons25 хоть прямо screen, именно ТОЧНО ИЗОБРАЖАЛ а не просто ставил соотв. переменную TERM (в отличие от того же PuTTY — представится может кем угодно, но реально xterm понимает и всё). Но это уже другая история.
Нам нужно было, чтобы клиенты могли посмотреть на то, что было на консоли до момента подключения. Например, что туда написало ядро.
А вот читать termcap (и вообще, что-то делать подобное внутри клиентской машины) мы не можем — чужое хозяйство всё-таки.
А вот читать termcap (и вообще, что-то делать подобное внутри клиентской машины) мы не можем — чужое хозяйство всё-таки.
На будущее, делайте пожалуйста хабракат намного меньше. а то оно у меня даже на одном экране не помещается.
Будете свою разработку выпускать в мир опенсорс?
Или оставите в закромах под лозунгом «наша библиотека — одна из лучших, и уж точно лучшая среди тех, которые не рисуют сразу же на экран» Бе-Бе-Бе
Спасибо, интересное чтиво.
Или оставите в закромах под лозунгом «наша библиотека — одна из лучших, и уж точно лучшая среди тех, которые не рисуют сразу же на экран» Бе-Бе-Бе
Спасибо, интересное чтиво.
Както тоже «писал» эмулятор терминала для графического приложения. Дальше корректного отображения «mc» неосилил.
Любопытный факт насчет клавиши BEEP в телетайпах. Многие наверное получали телеграммы, и видели на них странные буквы: «ЗЦЗЦ». Угадайте, что это было, с одного раза.
> to curse — высказывать благодарность за удобную и понятную вещь.
а ведь некоторые и не заметят издевку :)
> браузеры и их понимание того, что такое «нажатая кнопка»
небось Опера и IE больше всего доставили?
а ведь некоторые и не заметят издевку :)
> браузеры и их понимание того, что такое «нажатая кнопка»
небось Опера и IE больше всего доставили?
Консоль — это прекрасно!
А вообще панель облака будет меняться? Я перешел к вам недавно с Clodo и мне остро не хватает симпатичных графиков в реальном времени, и других красивостей.
Ну и писем на почту, сколько денег ушло за вчера, тоже не хватает.
А вообще панель облака будет меняться? Я перешел к вам недавно с Clodo и мне остро не хватает симпатичных графиков в реальном времени, и других красивостей.
Ну и писем на почту, сколько денег ушло за вчера, тоже не хватает.
Жаль что в этой интересной статье основной упор делается на Unix/Linux-терминалы.
Дело в том, что в Windows тоже есть совсем даже неплохой терминальный интерфейс VTNT.
Причем символы изначально кодируются в нем в UNICODE (это к вопросу о поддержки иероглифов).
Кстати на сайте MSDN есть очень подробная документация про него.
Формат обмена гораздо проще и прозрачнее чем у никсовых терминалок.
И, так же поддерживается более широкий диапазон сочетаний клавиш.
В этом интерфейсе (в его стандартной реализации) есть парочка недостатков:
1) гораздо больший объем сетевого трафика, создаваемый как нажатием кнопки, так и отображением символа (что не слишком критично для локального применения, а так же может быть решено компрессией передаваемого трафика).
2) отсутствие встроенной поддержки мыши (впрочем как и у остальных VTxxx терминалов).
Дело в том, что в Windows тоже есть совсем даже неплохой терминальный интерфейс VTNT.
Причем символы изначально кодируются в нем в UNICODE (это к вопросу о поддержки иероглифов).
Кстати на сайте MSDN есть очень подробная документация про него.
Формат обмена гораздо проще и прозрачнее чем у никсовых терминалок.
И, так же поддерживается более широкий диапазон сочетаний клавиш.
В этом интерфейсе (в его стандартной реализации) есть парочка недостатков:
1) гораздо больший объем сетевого трафика, создаваемый как нажатием кнопки, так и отображением символа (что не слишком критично для локального применения, а так же может быть решено компрессией передаваемого трафика).
2) отсутствие встроенной поддержки мыши (впрочем как и у остальных VTxxx терминалов).
Кстати в Microsoft, в реализации своего VTNT изначально решили эмулировать не печатающую машинку, и даже не телетайп, а, сразу — компьютерную консоль (совместимую с Win-API).
Это обстоятельство очень выгодно отличает VTNT от других VTxxx.
Это обстоятельство очень выгодно отличает VTNT от других VTxxx.
В статье описывается решение вполне реальной задачи. А зачем нужна очередная реализация VTNT — не преставляю.
На сколько я понимаю, описываемый в статье эмулятор терминала будет запускаться как в никсах так и в виндах.
Я считаю логичнее было бы добавить пользователю облака самому выбрать терминальный клиент (например путти).
Если б я был пользователем этого облака, то захотел бы использовать программу telnet.exe, встроенную в коробку с виндой.
из предлагаемых типов терминалов (ansi, vt100, vt52 и vtnt) разумеется отдал бы предпочтение именно vtnt.
П.С.: Почему именно я предпочел бы встроенную, проверенную временем, надежную фирменную реализацию клиентского терминала новомодному велосипеду — риторический вопрос.
Я считаю логичнее было бы добавить пользователю облака самому выбрать терминальный клиент (например путти).
Если б я был пользователем этого облака, то захотел бы использовать программу telnet.exe, встроенную в коробку с виндой.
из предлагаемых типов терминалов (ansi, vt100, vt52 и vtnt) разумеется отдал бы предпочтение именно vtnt.
П.С.: Почему именно я предпочел бы встроенную, проверенную временем, надежную фирменную реализацию клиентского терминала новомодному велосипеду — риторический вопрос.
Удачи работы в телнете по публичным wifi-сетям.
Я думаю, что не нужно лишний раз напоминать о возможности использования всяких защищенных туннелей, которые как раз и предназначены для того чтобы смело запускать телнеты (впрочем так же как и попы и эсмтэпы) в публичных вайфай (и эзернет) сетях.
Ну да, типичный MS-way. Вместо SSL городить туннели, главное ни в коем случае не использовать нормальный ssh (который ещё много чего умеет, чем просто кнопочки передавать), а тащить античный и глючный telnet.
Вы меня пытаетесь убедить, что нужно реализовать совместимость с MS, а я вот не вижу никаких коммерческих преимуществ в поддержке этой рухляди.
Вы меня пытаетесь убедить, что нужно реализовать совместимость с MS, а я вот не вижу никаких коммерческих преимуществ в поддержке этой рухляди.
Вообще мне хочется облако с возможностью запускать в нем виндовые проги (а, конкретно, Far-Manager с его кучей плагинов)
Как в облаке будет реализована подсистема запуска виндовых приложений (через эмулятор или виртуальную машину) меня как пользователя не должно сильно волновать (найти подходящее облако — всего лишь дело времени).
Меня больше интересует именно форма взаимодействия с виндовыми приложениями.
Виндовые приложения в подавляющем большинстве используют мышу!
Встроенный в винду телнет мышу не поддерживает.
Я ожидаю от разработчиков велосипедных терминалов вменяемой поддержки мыши.
Пусть эта поддержка будет через специальное приложение-эмулятор, с этим я готов смириться.
Но, блин, оставьте мне совместимость Win-API (в образе VTNT), для возможности замены велосипедного клиента своим собственным клиентом, способным эмулировать эмулятор терминала с поддержкой мыши.
пусть даже на другом конце облака будет и не виндовое приложение, а никсовое, но с мышою.
мой телнет с блек-джеком и мышами должен продолжать работать как ни в чем ни бывало.
Как в облаке будет реализована подсистема запуска виндовых приложений (через эмулятор или виртуальную машину) меня как пользователя не должно сильно волновать (найти подходящее облако — всего лишь дело времени).
Меня больше интересует именно форма взаимодействия с виндовыми приложениями.
Виндовые приложения в подавляющем большинстве используют мышу!
Встроенный в винду телнет мышу не поддерживает.
Я ожидаю от разработчиков велосипедных терминалов вменяемой поддержки мыши.
Пусть эта поддержка будет через специальное приложение-эмулятор, с этим я готов смириться.
Но, блин, оставьте мне совместимость Win-API (в образе VTNT), для возможности замены велосипедного клиента своим собственным клиентом, способным эмулировать эмулятор терминала с поддержкой мыши.
пусть даже на другом конце облака будет и не виндовое приложение, а никсовое, но с мышою.
мой телнет с блек-джеком и мышами должен продолжать работать как ни в чем ни бывало.
пусть даже на другом конце облака будет и не виндовое приложение, а никсовое, но с мышою.Ты хочешь работать с никсовым приложением в VTNT? Удачи.
Извините, у нас есть услуга «VDS'ы на hyper-v», там вам майкрософт три раза сделает приятно.
А с оплатой по потреблению винды не будет по простой причине: майкрософт хочет денег за лицензию. А я не хочу херить красивую модель оплаты ресурсов по потреблению какими-то дурацкими лицензионными отчислениями, которые стоимость вхождения в услугу увеличат раз так в 5-7.
А с оплатой по потреблению винды не будет по простой причине: майкрософт хочет денег за лицензию. А я не хочу херить красивую модель оплаты ресурсов по потреблению какими-то дурацкими лицензионными отчислениями, которые стоимость вхождения в услугу увеличат раз так в 5-7.
Ага, я тоже когда то открыл эту банку с червями, когда хотел написать эмулятор терминала на JS. Посмотрел, написал только самое необходимое и закрыл в ужасе.
НЛО прилетело и опубликовало эту надпись здесь
>это андроидный смартбук.
Toshiba AC100?
Toshiba AC100?
Она самая. Браузеры (все) под андроид более отвратительны, чем ожно было бы ожидать. Дурацкая покупка. Сначала я думал «ну, это с непривычки», а потом я взял с собой в отпуск только её — и понял, что так жить нельзя. Финал я писал с помощью vim'а в connectbot'е по ssh на свой сотовый (!) телефон (n900).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сага о том, как мы писали консоль