Selectel corporate blog
Comments 91
+9
Браво! Замечательная статья! Читается лучше иной художки!
+1
Интересная статья, но маловато технических подробностей конкретно вашей реализации эмулятора терминала(а не пишущих машинок вообще).
+10
Кстати, название ncurses — библиотеки для рендеринга изображения с использованием esc-кодов, вообще говоря, идёт от английского to curse — высказывать благодарность за удобную и понятную вещь.
Вот это красиво завернуто :)
0
а вот разве 'to curse' не переводится как 'проклинать'?: )
0
Очень не хватает вменяемой реализации n-Curses для Windows.
Всякий раз приходится свое велосипедить.
+6
>сражавшийся с бездной легаси, си и longjump'ов в коде
Примерно так ад программистов я себе и представлял, да.
+1
>>Потом, когда писали линукс, …
>>Тем же путём, кстати, пошёл UNUX и его клоны: solaris, FreeBSD, hp-ux и т.д.

Вообще-то это линукс пошел по пути UNIX. Вы путатете яйца с курицей =)
+1
Я не писал это перечисление в хронологическом порядке. Понятно, что юникс немного старше линукса.
-1
Поправьте эпиграф

Если посадить тысячу мартышек на за тысячу пишущих машинок…
+2
Мой друг когда-то пытался написать терминалку и интересуется, поддерживает ли ваша радость символы занимающие два и более знакомест (CJK иероглифы и прочее)?
+2
с большой вероятностью нет, т.к. мы юникод поддерживаем в смысле «не режем посредине многобайтного символа». Все операции, связанные с выводом комбинированных или нестандартных по расположению знаков мы просто не делаем, т.к. не разбираемся в содержимом юникода.

Если возникнет проблема — сделаем.
0
Да.
Попробуйте создать несколько файлов именами из «нихонги» и открыть эту директорию в mc.
У mc должны поехать рамки.
0
От иероглифов с большой вероятностью не полезет (консоль использует моноширинные и только моноширинные глифы), а вот от комбинированных символов — да (когда глиф на экране формируется несколькими символами). Но поддержка по��обных символов потребует, чтобы библиотека, отрабатывающая команды, знала что-то вообще о том, что за символ ей скормили — а это отдельный сложный мир.
0
Иероглифы традиционно занимают 2 знакоместа, комбинирующие символы (и всякие null-width space) — 0 знакомест. В любом случае нужно знать ширину символа.
0
Вообще, одно, насколько я с ними работал. Просто при их использовании остальные шрифты рисуются более крупно или с большими отступами.
0
Тут видно, что 本 ровно в 2 раза шире, чем остальные буквы.
Впрочем, половина старого *curses-софта даже при поддержке терминалом широких символов всё равно неправильно считает ширину.
-2
У меня тоже было желание написать свою терминалку с мышью и спрайтовой анимацией (что-то вроде расширенной псевдографики). Причем хотелось разработать терминальный интерфейс, совместимый с VTxxx на основе UTF-8 кодирования символов.
Идея такая: каждый спрайт представляет собой монохромное или цветное изображение (в том числе и анимированное и с поддержкой маски прозрачности для прорисовки нескольких «слоев»), занимающее на экране одно или несколько соседних знакомест.
Спрайт в потоке данных кодируется как обычный символ, кодом из UTF-8, и перед первым его использованием загружается его bitmap-образ (который представляет собой hex-последовательность символов, разделенных символом \х08 (BackSpace), для того чтобы, «старые» терминалы, не готовые к такому сценарию не выводили всякий «мусор» на экран).
Технически можно продумать вариант использования GIF-формата в качестве способа представления спрайта.
Набор загружаемых спрайтов фактически является «цветным растровым шрифтом».
Идея загрузки «шрифта» была позаимствована у матричных принтеров Epson.
Таким образом спрайты позволят на порядок расширить возможности ASCII-ART'а и псевдографики.
О готовности обмена спрайтами (в том числе и о размерах матрицы знакоместа) терминальный сервер и терминальный клиент могут «договориться» с помощью протокола TELNET.
Хотелось сделать поддержку работы терминала в полноэкранном графическом режиме.
Оставалось только продумать, как кодировать перемещение мыши.
Кстати, в старые-добрые времена, некоторые DOS-программы, работавшие полностью в текстовом режиме (например Нортон-утилиты) умели очень хитро делать эмуляцию CGA-курсора мыши в виде стрелки.
А, кодирование Unicode, позволило бы использовать и иероглифы в терминалке.
0
Таким образом, вы РИСУЕТЕ ТЕКСТОВУЮ консоль? А зачем!? Почему не отдавать её ниболее естественным образом — по telnet (ssh) и пустьу пользователя все эти коды обрабатываются хоть в PuTTY хоть в xterm хоть где? Зачем удалённый эмулятор консоли вообще нужен?
0
Т.е. я не очень понимаю use case — нужно видеть консоль виртуальной машины именно из браузера. Как-то мне кажется, что те, кому надо видеть консоль, обладают более адекватными инструментами для наблюдения консоли вместо этих костылей, paste в браузере и война с пониманием браузером клавиатуры.
-1
Ну вот я бы не отказался от терминала в JS, задолбали пользователи «а мы не умеем/боимся». Хотя таких JS-библиотек с десяток и все они лучшие и передовые. Меня тут скорее всего напрягло «Си» и «легаси» одном ряду. Это говорит о принципиальном усложнении ситуации и об ООП головного мозга.
UFO landed and left these words here
0
Эти пользователи и в КОНСОЛЬ не лазают. У тебя, впрочем, пользователям консоль и недоступна, что закономерно.
0
Вот пусть учатся лазать. Как это недоступно? Это ты чего на меня клевещешь? :)) Я как раз известен своей разумной паранойей. Со времён Петерхоста веб-мастеров в консоль гоню.
+1
Щорс, ты меня огорчаешь. Ты тоже путаешь консоль (getty + login — VGA + клавиатура или COM-порт, работает начиная от boot loader'а, а в серверных матерях прямо от BIOS'а, и туда ещё при старте ядра всякое про устройства пишется) и эмуляцию консоли (sshd/telnetd).

В консоль ты пользователей не пускаешь.

И вообще в консоль надо ОЧЕНЬ редко — когда у тебя сервер не грузится из-за косяков в конфигурации ядра или ты в файрволле набагал и тебя не пускают или файловая система не монтируется или при инсталляции sshd забыл разрешить. Короче, пользователям туда не надо, туда надо только руту и в случае дизастера а не для работы.
0
А, это-то. А, я забыл — это же облачники со своими виртаулками. Да, ты прав.
+2
По ssh люди и сами ходить могут. Пока не ломают себе в машине ssh. Собственно, именно для этого консоль и нужна.

Вообще, необходимость делать полноценный эмулятор возникла в основном из-за текстовых редакторов — если нужно поправить файл, то иногда это нужно делать с консоли, а vim, nano и mcedit покрывают, наверное, процентов 95% всех ESC кодов и сложных случаев отрисовки.
0
Если добавить в полноценный эмулятор вменяемую поддержку мыши, то он станет еще полноценнее)
+2
Мы об этом думали, технически там никаких особых проблем нет. Думаю, если в этом будет какая-то реальная потребность, то можно будет доделать. От библиотеки там почти ничего и не требуется-то, в основном вся нагрузка на JS пойдёт.
0
Конечно же есть необходимость!
Большинство современных текстовых редакторов используют мышь!
+1
ИМХО там довольно ограниченное взаимодействие. Ну, во-всяком случае, я в консоли gpm обычно не использую.
-3
Блин, тут речь идет не о личных предпочтениях.
Я ж ведь сам могу свой софт написать, который интенсивно использует мышу и захотеть запустить его в облаке.
+2
Именно в консоли? Текстовой? Ну, там, куда dmesg выводится? Не эмуляции консоли через sshd/telnetd, а в настоящей, аппаратной консоли (которая, конечно, виртуализируется XEN'ом, но это уже детали)? Мне сложно себе представить такой софт. Приведите пример.
+1
поправка, зен не эмулирует консоль, он эмулирует последовательный порт.
0
Запускайте, кто ж вам мешает.

JFYI: консоль в зене — последовательный порт. И она может ровно то, что может делать линукс на последовательном порте.
0
Обработка javascript'ом всех трёх кнопок мыши + их же с зажатым shift, и это не считая некоторого усложнения кода терминала. Ради нескольких приложений, прекрасно работающих и без мыши. Зачем?
-2
Дык ведь этот велосипедный терминал как раз и изобретается только для поддержки всего лишь нескольких приложений, прекрасно работающих в том числе и с мышью.
Ведь с этими приложениями можно же и так работать например через то же путти.
0
Не факт, что можно. Терминал в принципе работает без сети на конкретной машине.
В теории можно тупо форвардить/проксировать (чтобы видеть лог выключения) текстовый поток, но я не знаю подводных камней.
+1
Я знаю, мы этот вопрос прорабатывали, но там уж очень мерзко получается с организацией безопасного доступа.

Плюс, там не сохранялся бы вывод до момента подключения.
0
Вы не поняли.
Консоль в ssh. Человек делает «ssh user@consoles.hoster.tld» (обратите внимание — не root@server.of.user.tld), вводит пароль, ему показывают список его [вирутальных] серверов, он выбирает, видит именно КОНСОЛЬ.
Всё что нужно — поставить вместо шелла ему программку, которая будет получать те самые данные которые вы интерпретируете своей библиотекой и отправлять их пользователю как поток байтов.
Зачем браузер, зачем бибилиотека?
0
Думаю, что если бы топикстартер представлял объём работы заранее, он бы так и сделал.
0
Ну вот мне кажется, что это вообще две разные, малосвязаные между собой, задачи — -дать консоль пользователям и сделать эмулятор терминала в браузере. Можно сначала сделать первое малой кровью, а потом уже развелкаться терминалами на Java/JS в свободное время (кстати, терминал в виде апплета и даже, более того, ssh-клиент в виде апплета я видел много лет назад).

Конечно, потом таким терминалом из браузера можно будет подключаться И К КОНСОЛИ тоже, но, в целом эти две задачи никак не связаны и гораздо лучше их решать по отдельности — получается два законченных решения каждое из которых может работать в связке с другими (на консоль можно ходить любым терминалом, терминалом можно ходить на любые хосты) — а так получается вещь в себе за много денег (человекочасов).

Меня удивляет именно постановка задачи — она мне кажется непродуманной, мягко говоря.
+1
Э… истории не будет. Мы этот вариант прорабатывали. Либо нам нужно писать аналог screen (screeen в данном случае не подходит), либо человек остаётся без вывода до момента подключения.
-1
Всё что нужно — писать в файл всё и скармливать файл при подключении, зачем аналог Screen, зачем хранить картинку? Она быстро-быстро отрисуется при подключении.
+2
Разорвёте esc-код в середине — побъёте картинку. Потенциально — до состояния нечитаемой.

Будете сохранять всё — где ж вы эти десятки и сотни мегабайт хранить будете?
+1
Сотни мегабайт?! Эмм… Я не знаю, как эти ваши линуксы, а FreeBSD хорошо если пару килобайт в день на консоль выводит. Ну будет МЕГАБАЙТ на клиента — ну подарите вы ему этот мегабайт стораджа, проблем-то, он вам за сотни мегабайт платит.
+3
while true;do rmmod ixgbe;modprobe ixgbe;done — и 64к/сек помойки вам обеспечено. (при условии, что у вас не 10Г сетевуха). То же самое может быть от любого модуля ядра.

Я не говорю, что это все делают, я говорю, «что делать будем, если таковой объявится»? Мы в тестах консоли вполне делали hexdump /dev/random'а.

Главная разница провайдера и энтрепрайза, что в энтерпрайзе можно сказать «не делайте так», а провайдер должен быть готов к любому поведению.
+1
Да, и про историю я ничего не писал, кстати. Когда я подключаюсь к своему физическому серверу по COM-порту в случае если он перестаёт отвечать по сети — у меня нет никакой истории :) Тут ровно та же петрушка. Всё, что вам было нужно — заворачивать виртуальный ком-порт в ssh по требованию (подключению к ssh) — зачем вам была вообще эта эмуляция?

Нет, задача интересная, я бы с удовольствием такое попрограммировал за денежки, мотивацию программиста я хорошо понимаю. Мотивацию бизнеса давать на это деньги — не понимаю.

Кстати, был такой ssh-клиент на винде — telneat, в последствие ShellGuard. И вот он умел эмулировать любой терминал по термкапу. Т.е. он читал termcap и настраивал себя по нему — как делает [n]curses с КЛИЕНТСКОЙ стороны (для вывода), только наоборот. Его исходники болтались в сети, на С/C++, очень аккуратно написан был. Более точной эмуляции, например, FreeBSD'шной cons25 я не видел :) А ему было пофигу кого изображать — он одинаково точно делал хоть vt100 хоть xterm хоть cons25 хоть прямо screen, именно ТОЧНО ИЗОБРАЖАЛ а не просто ставил соотв. переменную TERM (в отличие от того же PuTTY — представится может кем угодно, но реально xterm понимает и всё). Но это уже другая история.
0
Нам нужно было, чтобы клиенты могли посмотреть на то, что было на консоли до момента подключения. Например, что туда написало ядро.

А вот читать termcap (и вообще, что-то делать подобное внутри клиентской машины) мы не можем — чужое хозяйство всё-таки.
+1
И как вы тогда узнаёте как рисовать? В смысле, в языке какого терминала говорит данная конкретная консоль? :)
0
TERM=linux. Мы этого не знаем — мы можем сказать «кто мы», если терминалка попросит, но влиять на TERM клиента мы не можем. По-умолчанию в линуксе тип терминала linux. На это и рассчитано. Если бы могли — писали бы xterm, разумеется, т.к. там фич больше.
0
На будущее, делайте пожалуйста хабракат намного меньше. а то оно у меня даже на одном экране не помещается.
+4
Будете свою разработку выпускать в мир опенсорс?

Или оставите в закромах под лозунгом «наша библиотека — одна из лучших, и уж точно лучшая среди тех, которые не рисуют сразу же на экран» Бе-Бе-Бе

Спасибо, интересное чтиво.
+6
Вы не поверите, но будем. Вот выйду из отпуска, формализмы закончу и будет публичный релиз под свободной лицензией.
0
Както тоже «писал» эмулятор терминала для графического приложения. Дальше корректного отображения «mc» неосилил.
UFO landed and left these words here
0
Писал на C++, большую часть брал из какойто нето Java, нето C# библиотеки. Это была отладочная/вспомогательная консоль в полноэкранном OpenGL приложении. Ввод в «mc» не заработал и я «забил». Посмотреть нигде нельзя.
+2
Любопытный факт насчет клавиши BEEP в телетайпах. Многие наверное получали телеграммы, и видели на них странные буквы: «ЗЦЗЦ». Угадайте, что это было, с одного раза.
+2
Мне кажется Вы немного переоцениваете возраст сообщества.
+1
> to curse — высказывать благодарность за удобную и понятную вещь.
а ведь некоторые и не заметят издевку :)
> браузеры и их понимание того, что такое «нажатая кнопка»
небось Опера и IE больше всего доставили?
+6
(счастливо улыбаясь) Мы с самого начала забили на поддержку IE, так что о проблемах IE мы не имеем ни малейшего представления.

ЗЫ Причина простая: ни у кого из разработчиков не было под рукой IE, а в силу того, что MS не выпустила дистрибутива для MacOS/Linux, то и взять его было негде.
+9
То есть вы хотите сказать, что мы должны были купить IE за 4 с половиной тысячи рублей? Э… только ради того, чтобы реализовать его поддержку? А после этого выкинуть, ибо ничего толвого эта штука не умеет?

Спасибо, не надо.
+2
Консоль — это прекрасно!

А вообще панель облака будет меняться? Я перешел к вам недавно с Clodo и мне остро не хватает симпатичных графиков в реальном времени, и других красивостей.
Ну и писем на почту, сколько денег ушло за вчера, тоже не хватает.
+5
будет, работаем. Текущая стагнация в развитии веб-морды — причина того, что делается другая морда.
-5
Жаль что в этой интересной статье основной упор делается на Unix/Linux-терминалы.
Дело в том, что в Windows тоже есть совсем даже неплохой терминальный интерфейс VTNT.
Причем символы изначально кодируются в нем в UNICODE (это к вопросу о поддержки иероглифов).
Кстати на сайте MSDN есть очень подробная документация про него.
Формат обмена гораздо проще и прозрачнее чем у никсовых терминалок.
И, так же поддерживается более широкий диапазон сочетаний клавиш.
В этом интерфейсе (в его стандартной реализации) есть парочка недостатков:
1) гораздо больший объем сетевого трафика, создаваемый как нажатием кнопки, так и отображением символа (что не слишком критично для локального применения, а так же может быть решено компрессией передаваемого трафика).
2) отсутствие встроенной поддержки мыши (впрочем как и у остальных VTxxx терминалов).
-2
Кстати в Microsoft, в реализации своего VTNT изначально решили эмулировать не печатающую машинку, и даже не телетайп, а, сразу — компьютерную консоль (совместимую с Win-API).
Это обстоятельство очень выгодно отличает VTNT от других VTxxx.
+2
В статье описывается решение вполне реальной задачи. А зачем нужна очередная реализация VTNT — не преставляю.
-6
На сколько я понимаю, описываемый в статье эмулятор терминала будет запускаться как в никсах так и в виндах.
Я считаю логичнее было бы добавить пользователю облака самому выбрать терминальный клиент (например путти).
Если б я был пользователем этого облака, то захотел бы использовать программу telnet.exe, встроенную в коробку с виндой.
из предлагаемых типов терминалов (ansi, vt100, vt52 и vtnt) разумеется отдал бы предпочтение именно vtnt.

П.С.: Почему именно я предпочел бы встроенную, проверенную временем, надежную фирменную реализацию клиентского терминала новомодному велосипеду — риторический вопрос.
-4
Я думаю, что не нужно лишний раз напоминать о возможности использования всяких защищенных туннелей, которые как раз и предназначены для того чтобы смело запускать телнеты (впрочем так же как и попы и эсмтэпы) в публичных вайфай (и эзернет) сетях.
+7
Ну да, типичный MS-way. Вместо SSL городить туннели, главное ни в коем случае не использовать нормальный ssh (который ещё много чего умеет, чем просто кнопочки передавать), а тащить античный и глючный telnet.

Вы меня пытаетесь убедить, что нужно реализовать совместимость с MS, а я вот не вижу никаких коммерческих преимуществ в поддержке этой рухляди.
-6
Вообще мне хочется облако с возможностью запускать в нем виндовые проги (а, конкретно, Far-Manager с его кучей плагинов)
Как в облаке будет реализована подсистема запуска виндовых приложений (через эмулятор или виртуальную машину) меня как пользователя не должно сильно волновать (найти подходящее облако — всего лишь дело времени).
Меня больше интересует именно форма взаимодействия с виндовыми приложениями.
Виндовые приложения в подавляющем большинстве используют мышу!
Встроенный в винду телнет мышу не поддерживает.
Я ожидаю от разработчиков велосипедных терминалов вменяемой поддержки мыши.
Пусть эта поддержка будет через специальное приложение-эмулятор, с этим я готов ��мириться.
Но, блин, оставьте мне совместимость Win-API (в образе VTNT), для возможности замены велосипедного клиента своим собственным клиентом, способным эмулировать эмулятор терминала с поддержкой мыши.
пусть даже на другом конце облака будет и не виндовое приложение, а никсовое, но с мышою.
мой телнет с блек-джеком и мышами должен продолжать работать как ни в чем ни бывало.
+2
пусть даже на другом конце облака будет и не виндовое приложение, а никсовое, но с мышою.
Ты хочешь работать с никсовым приложением в VTNT? Удачи.
+8
Извините, у нас есть услуга «VDS'ы на hyper-v», там вам майкрософт три раза сделает приятно.

А с оплатой по потреблению винды не будет по простой причине: майкрософт хочет денег за лицензию. А я не хочу херить красивую модель оплаты ресурсов по потреблению какими-то дурацкими лицензионными отчислениями, которые стоимость вхождения в услугу увеличат раз так в 5-7.
+2
Ага, я тоже когда то открыл эту банку с червями, когда хотел написать эмулятор терминала на JS. Посмотрел, написал только самое необходимое и закрыл в ужасе.
0
2 месяца сложной технической работы… прямо подвиг! Оно того реально стоило? Более важных проблем и задач у селектела сейчас нет? :)

Спрашиваю, потому как слежу за развитием и хочу попробовать это облако после неудачной попытки с Clodo. Всё в принципе привлекает, кроме грустных замечаний некоторых знакомых бизнесменов из серии «я за несколько лет по российским хостерам столько бегал, что теперь только Европа! Было бы круто увидеть пост на эту тему — о сравнении наших и „ихних“ облачных хостингов в плане не только цен, но и отказоустойчивости/качества/саппорта.
+4
Никто не ожидал, что это будет так долго. А консоль нам нужна была, потому что без этого дальнейшее развитие инфраструктуры невозможно (многие операции с машинами потребуют netless доступа к машине).
+1
Она самая. Браузеры (все) под андроид более отвратительны, чем ожно было бы ожидать. Дурацкая покупка. Сначала я думал «ну, это с непривычки», а потом я взял с собой в отпуск только её — и понял, что так жить нельзя. Финал я писал с помощью vim'а в connectbot'е по ssh на свой сотовый (!) телефон (n900).
Only those users with full accounts are able to leave comments., please.