Комментарии 28
А зачем нужен удаленный доступ на уровне приложения, а не целиком для ОС? Пользователям сложно настраивать доступ по RDP, nomachine и т.п., или работа на уровне приложения позволяет что-нибудь оптимизировать?
Тот же VS Code требует гораздо меньшую ширину канала для комфортной работы, чем RDP или VNC.
Как минимум, у вас будут нормальные красивые векторные шрифты без малейших артефактов сжатия. При этом, количество трафика и отзывчивость — выше, чем у Remote Desktop или VNC.
А еще, всё это — очень короткий, лаконичный код на Kotlin, вокруг которого можно строить свою инфраструктуру — например, какой-то сервис облачной раздачи IDE с помощью Kubernetes. Это актуально для больших компаний.
Идея хороша, но...
- По скорости — явно тормознутее чем VNC.
- Только одно окно, т.е. сразу с несколькими проектами не поработать, разве что цепляться к каждому отдельно, что тоже неудобно (хотя может это ограничение только плагина)
- Самое неприятное — оно ужасно смотрится на 4k мониторе, просто ужасно огромный шрифт и не видно никаких настроек на этот счёт
- "нативный" клиент оказался обычным замаскированным браузером — т.е. высокой производительности от него ожидать явно не приходится (может поэтому VNC быстрее).
По скорости — явно тормознутее чем VNC.
В моих замерах всё обычно наоборот, он тратит меньше трафика чем VNC в режиме качества, и работает отзывчивей. Какой у вас провайдер, откуда до куда вы соединяетесь, какая скорость сети, какой пинг?
Собственно, это одно из ключевых преимуществ Прожектора — скорость. Есть люди, которые работают из Индии с IDE, которые запущены в дата-центре в Европе — им было очень плохо на VNC, и гораздо лучше на Прожекторе.
С vnc лучше не сравнивать, т.к. явно не самый быстрый протокол. Если и сравнивать, то хотя бы с последними версиями rdp но только под виндой (линукс клиенты всетаки отстают значительно)
Я проверял в локалке, соответственно скорость 1 Gb/s, сеть не нагружена (ping < 1ms, потерь нет), комп тоже ничем не занят. VNC я использую с lossless сжатием, т.е. качество по максимуму.
При работе с VNC всё летает (если окна не таскать), а вот через Projector — очень ощутимый лаг, особенно при скроллинге, в общем очень некомфортно.
Спасибо! Если vnc летает, то rdp будет вообще ракета :)
Тогда мой текущий вариант через rdp не имеет смысла менять
Вот кстати у меня тоже тормозит, хотя X11 норм. Сетевой пинг <1мс. Я пробовал и хром, и отдельный клиент. При показе пинга в клиенте (это когда коннектишься с указанием параметра для показа пинга) заметно что он иногда проседает до 10сек.
То есть это не Swing-proxy с хитрой сериализацией, а просто VNC?
Вы опоздали с публикацией примерно на год.
Однако за отдельный плагин спасибо, он делает всё гораздо проще! (если для php/python IDE в докере ещё сносный вариант, то вот для С++ окружения нужно больше; просто докер с проектором и clion, без нужных либ/хедеров, собственно, для самой разработки уже не так полезен)
Всем нужные разные схемы безопасности. Сейчас нет возможности реализовать десятки схем, которые хотят разные организации и люди. В качестве обходного маневра, можно использовать VPN, и выбрать тот VPN с теми настройками, которые вам нужны.
Главное что нужно все равно подключаться по rdp/vnc/… и подтверждать подключение.
Да и для того что бы запустить сеанс тоже надо подключится (автостарт сервера в настройках одним параметром и отключение подтверждения коннекта наверно не сложно добавить).
Жаль, придется остаться без ответов на вопросы…
Остается только пожелать удачи asm0dey с его докладом :) Ну а я подожду публикации в открытом доступе.
Выглядит очень хорошо! подобного жду уже лет 5 (если не больше) от разных IDE.
В NetBeans была возможность законнектиться по ssh, но сам движек работал локально и просматривал весь проект по ssh — в итоге ужастные тормоза на проектах больше хеллоу ворд.
Часто не хочется (и не возможно) на столе держать большую машину для комфортной работы Clion, быстрой сборки и тем более запуска вычислений приложений. Если с первым и вторым смирился, то запуск точно на удаленном сервере. Благо в Clion есть автодеплой, это спасает.
Но вот если архитектура на удаленном сервере отличается от той что на клиенте (например ppc64le)? Всячески откладываю внедрение кросс-компиляции, хотя и работу Clion на ppc64le ждать наивно.
Разрабатываем хоть десктопное приложение, хоть веб-приложение, хоть консольное — его ж надо хоть иногда запускать и смотреть результаты, а как это делать, если удалённо доступна лишь IDE? Получается, что более-менее просто можно только запускать автотесты и command line apps (если они настроены именно в IDE через Run Configurations)?
Скорее всего я упускаю что-то очевидное. olegchir, с помощью Projector можно же как-то потыкать в web приложение запущенное на машине с IDE или внутри корпоративного облака?
Удаленный доступ к IDE при помощи Projector