Будущее удалённых рабочих мест
13.11.2021
|
velkin
 |
Содержание.
1. Что такое удалённое рабочее место.
1.1 Удалённое рабочее место удалено от сотрудника.
1.2 Удалённое рабочее место не принадлежит сотруднику.
2. Что не является удалённым рабочим местом.
2.1 Личный или офисный компьютер со шпионским ПО.
2.2 Личный или офисный компьютер без шпионского ПО.
3. Преимущества удалённых рабочих мест.
3.1 Рабочее место для удалённых сотрудников.
3.2 Удалённый найм для удалённых сотрудников.
3.3 Совместная работа для удалённых сотрудников.
3.4 Обезличивание организаций нанимающих удалённых сотрудников.
3.5 Совершенствование процессов организации с удалёнными рабочими местами.
4. Решения для создания удалённых рабочих мест.
4.1 VMWare vSphere ESXi.
4.2 Microsoft Hyper-V Server.
4.3 Proxmox Virtual Environment.
4.4 OpenNode.
5. Часто задаваемые вопросы.
1. Что такое удалённое рабочее место.
Давайте сразу определимся, что является удалённым рабочим местом, а что нет.
1) Удалённое рабочее место удалено от сотрудника.
************* *************************
* удалённое * * локальное * *
* рабочее * <=канал связи=> * рабочее * сотрудник *
* место * интернет локалка * место * *
************* *************************При этом сотрудник вынужден взаимодействовать с удалённым рабочим местом посредством локального рабочего места.
Канал связи может быть:
1) Сетью интернет.
2) Локальной сетью организации.
2) Удалённое рабочее место не принадлежит сотруднику.
******************* *********************
* администратор * * сотрудник *
* установка софта * * выполняет работу *
******************* *********************
* удалённое * * локальное *
* рабочее место * <=канал связи=> * рабочее место *
******************* интернет локалка *********************
* виртуальный * * личный компьютер *
* сервер * * офисный компьютер *
******************* *********************1) На своём локальном рабочем месте сотрудник может делать всё, что угодно.
2) На удалённом рабочем месте за установку операционной системы и софта, а так же за создания бекапов, отвечает администратор.
Для примера:
1) Если бухгалтеру нужен платный Windows и платный 1C об этом заботится работодатель посредством администратора.
2) Если программисту нужны конкретные версии IDE и прочие утилиты об этом тоже заботится работодатель посредством администратора.
Даже если сотрудник может что-то установить самостоятельно, то сделает он это не на локальное рабочее место, коим может быть:
1) Личный компьютер.
2) Офисный компьютер.
2. Что не является удалённым рабочим местом.
1) Личный или офисный компьютер со шпионским ПО.
Предположим работодатель:
1) Попросил установить сотрудника шпионское ПО на личный компьютер сотрудника, чтобы шпионить за ним.
2) Или установил шпионское ПО на офисный компьютер с теми же целями слежения за сотрудинком.
Очевидная причина почему это рабочее место не является удалённым в том, что оно не удалено от сотрудника. Даже если шпионское ПО позволит работодателю удалённо управлять этим рабочим местом этот контроль может легко прервать.
1) Сам сотрудник.
2) Силовые структуры пришедшие с проверкой в офис.
3) Внешние обстоятельства, вроде пожара, скачка напряжения и так далее.
2) Личный или офисный компьютер без шпионского ПО.
Даже если работодатель избавится от иллюзии контроля, место которое не удалено от сотрудника всё равно не станет удалённым для этого самого сотрудника.
Главным признаком удалённого рабочего места является его удалённость от сотрудника, тогда как по отношению к работодателю оно может находиться.
1) В датацентре.
2) В соседней комнате.
3) Под столом.
3. Преимущества удалённых рабочих мест.
1) Рабочее место для удалённых сотрудников.
Ну, такого наверное никто не ожидал, но тут нужно понимать, что:
1) удалённый сотрудник и
2) удалённое рабочее место
не равные понятия.
Удалённый сотрудник может работать как на удалённом рабочем месте, так и на локальном рабочем месте.
1) В данном случае сотрудник удалён от работодателя, потому и считается удалённым.
2) По отношению же к месту работы он может быть не удалён.
Потому запомните, удалённый сотрудник и удалённое рабочее место не обязаны пересекаться.
2) Удалённый найм для удалённых сотрудников.
Другое преимущество в том, что собеседования можно проводить прямо на удалённом от сотрудника рабочем месте вне зависимости от местоположения самого сотрудника. С полностью готовым окружением созданным для тестов сотрудников и отражающим реальные рабочие условия.
Конечно, хрюша женского пола скажет, что так нельзя. Нужно вызвать возможного сотрудника на собеседование. Посмотреть ему в глаза и узнать кто он альфа или омега. Помурыжить его на нескольких собеседованиях. Наорать и кинуть в него стакан, это нынче говорят такие стресс тесты.
А теперь поворачиваемся и с победной улыбкой заявляем, что всё это невозможно на как его, короче твоей виртуальной машине. Как ты стакан в работника кинешь? А если даже наорёшь по телефону, то потенциальный сотрудник просто повесит трубку. А через твою виртуальную машину даже наорать нормально не получится. Шах и мат тебе.
3) Совместная работа для удалённых сотрудников.
1) Это может быть как слежение менеджером, тимлидом или уборщицей за сотрудниками в целях понимания их эффективности.
2) Совместное подключение разработчиков к одной машине для реализации практик парного программирования, обмена опытом, обзоров кода.
3) Ну или не кода, в конце концов удалённо могут работать бухгалтеры, инженеры и прочие, ведь пробрасывать можно разное оборудование, от видеокарт до специализированных портов.
4) Обезличивание организаций нанимающих удалённых сотрудников.
1) Один сотрудник может не знать о других, следовательно не предоставит компромат на компанию.
2) Маски шоу врываются в пустые офисы и не могут парализовать работу компании изъяв оборудование.
3) Люди территориально сидят по всему миру, они функция, а не физическое тело.
4) Нанимаешь сотрудника как винтик и так же его увольняешь.
5) Совершенствование процессов организации с удалёнными рабочими местами.
Вопрос вот в чём:
1) Хочет ли собственник управлять организацией.
2) Или он надеется, что всё как-нибудь само будет управляться.
Когда все рабочие места управляются централизованно велик риск очень и очень большой ошибки.
1) Ой, я случайно удалил кластер организации со всеми данными.
2) С другой стороны это даёт огромные возможности по реконструкции бизнес процессов.
С большой силой приходит большая ответственность
4. Решения для создания удалённых рабочих мест.
1) VMWare vSphere ESXi
2) Microsoft Hyper-V Server
3) ProxMox VE (KVM)
4) OpenNode (щито это?)
Моторолер не мой!!! Я просто разместил ОБЪЯВУ!
KVM я и так знаю как работает. Мне он даже нравится больше VirtualBox. Но есть одно но, VirtualBox я могу использовать в дуалбуте между Windows и Debian, а KVM нет.
А ProxMox VE это специализированный дистрибутив Debian, поставил его на виртуалку с нодой01, зашёл по https://192.168.1.100:8006.
По крайне мере эта штука работает, проверять я её конечно же не буду. И одно дело поставить Debian Proxmox VE на Debian, другое дело тестировать сильно платные продукты вроде ESXi, Hyper-V. У меня нет с ними сродства, а им ещё и хочется бабла.
5. Часто задаваемые вопросы.
Почему удалённые места не захватили мир?
Потому что большинство работодателей не верят в удалённые рабочие места. Они даже не понимают разницу между удалённым сотрудником и удалённым рабочим местом.
| 13.11.2021 34 комментария |
V>
2) Почему удалённые места не захватили мир?
Потому, что работник с правом выбора никогда не согласится работать через удаленный рабочий стол. Глаза и нервы дороже.
scf>Потому, что работник с правом выбора никогда не согласится работать через удаленный рабочий стол. Глаза и нервы дороже.
Я пробовал в одном и том же городе подключаться к удалённому рабочему столу.
1) Набирал код в IDE.
2) Играл в гонки.
В принципе и то и другое нормально, но конечно не так хорошо, как если используешь компьютер напрямую. Чувствуется недостаток кадров в секунду, хотя это не недостаток частоты кадров дисплея, а лишь передаваемых данных. Но в целом всё и не так плохо, как могло бы быть, даже играбельно и видео показывает через браузер на удалённой машине.
Подозреваю, что если сделать тоже самое через всю планету, то добавится задержка между вводом с устройства ввода и выводом на экран.
Но достаточная ли эта причина не использовать удалённое рабочее место?
Я считаю одним из условий успеха это выделение достаточного:
1) количества ядер процессора,
2) объёма оперативной памяти,
3) быстрого дискового пространства,
4) отзывчивого интернет канала.
То есть удалённое рабочее место это не экономия на "железе", а может даже совсем наоборот двойные траты на мощные сервера и производительные терминалы.
Если бы идея была только в экономии, то я бы даже не стал говорить о таком явлении, как удалённые рабочие места.
Что касается выбора работников, то я уже не раз читал мнения:
1) Мы не будем работать, удалённо.
2) Мы не будем работать, если кто-то посмотрит на наш экран.
3) Мы не будем работать, если надо писать какой-то отчёт.
4) Мы не будем работать, если нужно делать юнит тесты.
5) Мы не будем работать, когда нашу эффективность пытаются рассчитать.
И всё в таком роде. А полно людей которые будут работать. Люди в России работают за компьютером за $200-$300. Думаю, что удалённое рабочее место в этом случае наименьшая из проблем.
Потому я бы спросил так, а кто предоставляет работу через подключение к удалённому рабочему столу? А я вот не знаю. В статьях пишут, что эту технологию якобы используют колл-центры. Но что там и как мне неизвестно.
В общем всё понятно про то, что кто-то не хочет работать. Я вот тоже не хочу работать никак. И в опенспейсе не хочу и не буду.
Нет, только в шикарном особняке на море с отдельным рабочим кабинетом. И чтобы никто не шумел.
V>Здравствуйте, scf, Вы писали:
scf>>Потому, что работник с правом выбора никогда не согласится работать через удаленный рабочий стол. Глаза и нервы дороже.
V>Я пробовал в одном и том же городе подключаться к удалённому рабочему столу.
V>1) Набирал код в IDE.
V>2) Играл в гонки.
Нет, не нормально.
По моему личному опыту — разница между работой в IDE, запущенной на удалённом рабочем месте и в IDE, запущенной локально, но подключенной к удалённой БД (или репозиториям) очень сильно заметна.
При том, что удалённое рабочее место — весьма и весьма не слабой конфигурации, уровня Core i7 с 32 Гб оперативы.
Если в пределах одного города еще может получиться, что ваша офисная сеть и сеть локального РМ подключены к одной точке обмена трафиком, то при расположении удалённого рабочего места в Московском ЦОД, а локального рабочего места на дальнем востоке — латенси начинает ролять просто неимоверно и это никакой пропускной способностью сети не исправишь.
Поэтому можно прокинуть на локальную машину доступ к БД, можно подключить к локальной машине сетевые диски с файлами и репозиториями.
Но сама IDE должна выполняться локально, этот экспириенс ничем не заменить.
Когда IDE запущена на удалённой машине — можно только что-то "поправить на ходу".
Но перманентно по 8 часов в день работать в таком режиме — ОЧЕНЬ тяжело.
AN>Когда IDE запущена на удалённой машине — можно только что-то "поправить на ходу".
AN>Но перманентно по 8 часов в день работать в таком режиме — ОЧЕНЬ тяжело.
фигассе, это вы точно про 21год? а я думал шутите, мне ктото лапшу вешал про прогрессивную дигитализацию в РФ
pik>Здравствуйте, AndrewN, Вы писали:
pik>фигассе, это вы точно про 21год? а я думал шутите, мне ктото лапшу вешал про прогрессивную дигитализацию в РФ
Оу, а у благородного дона появился способ мгновенно без задержек прокинуть нажатие кнопки в Хабаровске на удалённый рабочий стол, расположенный в Москве и столь же мгновенно получить перерисованную картинку на мониторе в Хабаровске? Не поделитесь? Очень интересует, приму на вооружение и начну использовать в ежедневной работе.
И, да, речь не про качество сетей в Российской федерации (если ваш посыл был в этом).
Предположим, для простоты, что между Хабаровском и Москвой прямое оптоволокно лежит, длиной 6000 км.
AN>Оу, а у благородного дона появился способ мгновенно без задержек прокинуть нажатие кнопки в Хабаровске на удалённый рабочий стол, расположенный в Москве и столь же мгновенно получить перерисованную картинку на мониторе в Хабаровске? Не поделитесь? Очень интересует, приму на вооружение и начну использовать в ежедневной работе.
с Австралией, Японией и США работал через teamviewer без особых проблем.
для удалённой работы по всему ЕС используем банальный RDP, не точто кодить
но и картинку вживую вполне передаются, что в бюро что дома без разницы.
да вообще все операции без разницы, что удалённо что на месте.
могу только про W10 говорить, других уже давно не держим
V>Подозреваю, что если сделать тоже самое через всю планету, то добавится задержка между вводом с устройства ввода и выводом на экран.
V>Но достаточная ли эта причина не использовать удалённое рабочее место?
я десять раз посмотрел на дату этого сообщения
scf>>Потому, что работник с правом выбора никогда не согласится работать через удаленный рабочий стол. Глаза и нервы дороже.
V>Подозреваю, что если сделать тоже самое через всю планету, то добавится задержка между вводом с устройства ввода и выводом на экран.
Можешь не подозревать, проблема очень существенная даже на пути Москва->Лондон->Москва.
А напрямую у нас работать никак нельзя.
V>4) отзывчивого интернет канала.
А с этим фантастические проблемы. И никакая чипизация с 5G эту проблему никак не решают.
Нужен более-менее прямой канал и его нет.
V>Что касается выбора работников, то я уже не раз читал мнения:
V>1) Мы не будем работать, удалённо.
V>2) Мы не будем работать, если кто-то посмотрит на наш экран.
V>3) Мы не будем работать, если надо писать какой-то отчёт.
V>4) Мы не будем работать, если нужно делать юнит тесты.
V>5) Мы не будем работать, когда нашу эффективность пытаются рассчитать.
В общем-то это всё справедливо, только причины немного другие чем кажется:
1) помимо интернет канала, нужно работать где-то, помещение нужно. В жилом
секторе -- нереально. Я три съемных квартиры сменил и сейчас надо менять опять,
я уже не могу, сил нет. Соседи -- всегда соседи, редкостные уроды, у них
перманентный ремонт, собаки, забивание гвоздей в пол часами, и т.п.
Реальный вариант только аренда офиса, на заводе, в БЦ, где-то поблизости.
2) проблема не в том, что посмотрит, а что посмотрит, поймёт неправильно, и ещё
будет комментировать.
3) не проблема, без этого бизнес не работает. Но опять же есть проблема из п.2,
особенно если отчет читают не профессионалы.
4) чушь, скорей наоборот. я думаю надо отказываться от работы с людьми практикующими
нетрадиционные формы разработки ПО. В традиционную форму входит VCS, ревью, тесты, CI.
5) Опять же проблема из п. 2. Дело не в том, что попытаются расчитать, а что
при этом берётся какая-нибудь крайне идиотская метрика. Классика жанра, что
на ревью в конце месяца прибегает толпа народу и начинает рассказывать про
пропущенный пробел или лишнюю пустую строчку. Им это очень нужно, т.к. иначе
метрики по ревью не будут выполнены.
Практически по всем пунктам проблема в плохой метрике. Вася интегрировал чужой opensorce
проект, а Петя отлаживал говнокод написанный Васей, и так весь месяц. В итоге в KPI получается,
что Петя в говне, а Вася на коне, если по числу строчек считать, так что ли?
V>И всё в таком роде. А полно людей которые будут работать. Люди в России работают за компьютером за $200-$300. Думаю, что удалённое рабочее место в этом случае наименьшая из проблем.
Нет. В случае когда реакция на событие (например на нажатие клавиши) происходит за 300мс
(и пинг такого же порядка) -- работать в текстовом редакторе практически невозможно.
Во-первых когда текст пишешь -- вслепую (появляется с задержкой), нет обратной связи.
Во-вторых курсор осмысленно перемещать с клавиатуры практически невозможно (не попадаешь никуда,
мышкой-то понятно, получается т.к. координаты там абсолютные). Такая работа дико выматывает
и должна выполняться не более двух часов в день и с пятикратной оплатой. Вот что я думаю.
Практически сейчас всегда нужно редактор вытаскивать на локальную машину. Ну если очень
постараться, то можно в mosh и vim как-то там помучаться. Работать в консоли, кроме редактора,
можно удаленно и с большими задержками, хотя не всегда тоже возможно. Опять же задачи вроде
просмотра больших текстовых файлов (логов) вызывают проблему. Работать в GUI же можно только
для виду, ну почту может проверить, не более того.
V>Потому я бы спросил так, а кто предоставляет работу через подключение к удалённому рабочему столу?
У нас на работе предоставляют. Это полный πи3дeц. Причём там ещё админы очень старались
и сделали в несколько раз быстрей, чем было изначально. Через Цитрикс можно удалённо подключиться
к виртуалке, в которой всё приколочено гвоздями (даже иконки к десктопу), совершенно ничего
нельзя, даже батники запускать (но можно из VSCode запустить powershell, а там cmd.exe...)
Файлы на этой виртуалке сохранять нельзя, никакие настройки не сохраняются, всё теряется
при разрыве связи или если мышку не шевелить больше скольких-то минут (это реальная проблема,
как так работать, в сортире задержаться страшно!) Только есть сетевой диск, очень медленный,
и очень маленький. Так вот там работать вообще не нужно, там нужно скорей запускать RDP
и подключаться к офисной виндовой машине, потом на ней запускать ssh и подключаться к
офисной линуксовой машине. Вот как-то так. Задержки неебические в итоге и складываются
из того, что сигнал идёт через Лондон, и что сам Цитрикс всё прорисовывает
с задержкой (время уходит на кодирование/декодирование видео). Причём от виртуалки до
рабочей машины сделали RDP через UDP и стало в разы просто веселей, но сам Цитрикс -- TCP,
соответственно задержка большая (в UDP порядок пакетов не важен, потери не важны, поэтому
если что-то задержалось, то оно выкидывается, а TCP вынужден всё досылать и ждать
подтверждения, что приняли).
Технология не рабочая ВООБЩЕ. Обычный микрософтовский RDP намного лучше, но и там не сахар,
потому, что если тебе надо какое-то видео посмотреть, то без вариантов. Может тупо ширины
канала не хватить (он на лету в h.265 тебе кодировать же не будет). Ну т.е. тот же скайп
локально запускать надо, например. А как экран пошарить, если Цитрикс не даёт скриншоты делать?
Ну и само собой клипбоард работает только туда, а не оттуда. И вишенка на торте --
ватермарки по всему экрану такие, что текст читать мешают.
Реально этой херней думаю никто не пользуется и все придумывают отмазки чтоб не
пользоваться дальше: есть VPN, тоже тормозной, но там файлы гонять можно. С ним честно
говоря не легче, потому, что вытаскивать на ноут или тем более домашний комп
формально вообще нельзя и надо работать тоже удалённо. Ну и не вытащишь особо,
теоретически можно, но сам не захочешь. Потому, что всё окружение на ноуте поднимать
и мороки много, и объемы большие, и ноут слаб, и там первое-пятое-десятое, если через
git то будешь забывать его синхронизировать вручную в частности... Короче говоря удалённо
работать проще. Из вариантов более-менее работающих: либо mosh, либо VSCode
(которая таскает файлы через ssh и редактирует локально, без лагов). А сборка, запуск,
отладка, логи, и всё такое прочее -- строго удалённо. Логи проблема на самом деле,
в каком-то смысле. Их неудобно скачивать, их неудобно смотреть удалённо в mosh
(нет буфера "над экраном"), только в ssh, но там тормозит, что тоже неудобно.
Отдельной проблемой является навигация по коду и поиск. В принципе в VSCode кое-как
и кое-что работает, но далеко не все замечательно, например простую задачу
"найти все вхождения данного символа" VSCode решать не умеет (только через поиск,
где найдет вообще что попало). В Vim это все решается через ctags, global и какую-то
мать, ещё через git grep. Вроде там в Emacs всё аж волшебно, но я не умею. Но наверное
обманывают, и далеко не все там волшебно. Да, vim в режиме через netrw (с ssh://)
работает очень плохо, скорей никак. Если очень нужно, то так можно, но скорей не стоит.
С global он при этом перестанет работать, для ctags нужно файл tags патчить (к файлам
добавить префикс ssh://), git grep можно сделать через ssh (чтоб в окно вима попадало).
Еще проблемой является браузер, но решается через ssh и -D9050 прокси.
А с линуксом вообще беда. Там нет никакой нормальной технологии удалённого подключения,
только недоделки криворуких студентов. SSH в голом виде -- скорей нерабочая херня
(т.к. помирает от любого разрыва), screen, tmux и т.п. -- тоже нерабочая херня,
т.к. по разным причинам пользоваться ими невозможно, VNC нормально работает только
8-битном режиме (и то падает регулярно) с наркоманской расскраской приложений,
и тоже только TCP, RDP в линуксе даже есть, но тоже только TCP и тормозной
(микрософтовский намного быстрей/лучше). X11 forwarding вообще смешно, нормально
работает только в локалке или только с очень простыми приложениями. mosh тоже ещё
та недоделка, т.к. иногда хочется промотать буфер вверх -- а там ничего, и надо
подключаться ещё раз через ssh и всё повторять.
Ещё с монитором проблема. Если на работе 4к-монитор, а дома или в ноутбуке 96dpi,
то удалённые сервера/клиенты работающие по принципу screen scraper (копирования картинки
из сессии запущенной на реальном мониторе) выдают всё гигантского размера и оно
в маленький дисплей не лезет (а при уменьшении -- не читаемо). С виндами вообще всё
плохо, там нихера толком не настраивается. В линуксе можно отдельную сессию в Xvfb
запустить и там выкрутиться, но в целом -- траха много, толку мало.
V> А я вот не знаю. В статьях пишут, что эту технологию якобы используют колл-центры. Но что там и как мне неизвестно.
Для ряда профессий, где комп не основное -- оно может и годится. Для программиста
не годится. Крайне критична скорость реакции компьютера на ввод. Иначе -- формально
работать вроде можно, но на практике невозможно, т.к. у тебя 90% времени вместо
работы только раздражение от того, что нажал на кнопку -- нихера, нажал еще раз -- две буквы,
и все остальное в таком же духе. Просто выматывает очень сильно. Даже если вот как
сейчас текст пишешь, если не видишь на экране обратной связи -- мешает сильно.
Вот mosh очень сильно помогает, по крайней мере код писать можно, а то что курсор
с задержкой, так насобачиваешься в Vim его командами работать и уже не так заметно.
V>В общем всё понятно про то, что кто-то не хочет работать. Я вот тоже не хочу работать никак. И в опенспейсе не хочу и не буду.
Не вижу никакой проблемы в опенспейсе кроме сквозняков. Более того, зачатую в опенспейсе
_сильно_ _лучше_, чем в маленьких кабинетиках. Потому, что ТИШЕ, как ни странно. Потому, что
все источники звука поблизости рассеиваются в условно бесконечном просторе опенспейса и
превращаются в монотонный, не отвлекающий шум. А в маленьком кабинетике все бесконечно
переотражается от стен.
V>
При прочих равных я бы предпочел опенспейс. Плюс если тебе что-то мешает там
можно с ноутбуком куда-то мигрировать.
V>Нет, только в шикарном особняке на море с отдельным рабочим кабинетом. И чтобы никто не шумел.
У меня был кабинетик, там под окнами курили, на улице постоянный шум
(в опенспейсе как правило принудительная система вентиляции), из вентиляции
лезли мухи... Не тоскую.
scf>Потому, что работник с правом выбора никогда не согласится работать через удаленный рабочий стол. Глаза и нервы дороже.
А что мешает отнести домой рабочий ноутбук или компьютер и дальше по VPN лазить? Или вообще по SSH на рабочую машину в офисе залез и никаких задержек как класса нету
KP>А что мешает отнести домой рабочий ноутбук или компьютер и дальше по VPN лазить? Или вообще по SSH на рабочую машину в офисе залез и никаких задержек как класса нету
Идея интересная, и я не про VPN, это всего лишь сеть поверх другой сети, непонятно, что она в данном случае даст.
По поводу SSH, у меня есть сервера на мобильном интернете, то есть к симкам привязан статический ip. Когда я их админю в консоли вижу задержку и время отклика нестабильно. Очевидно, что с GUI будет не лучше, а только хуже.
Так же критически важно запускать установленные приложения именно на удалённом рабочем месте, а не у себя. То есть если это программист, то в итоге это не избавляет его от обязанности коммитить с удалённого рабочего места на сервер проекта.
Запуск графических приложений по ssh
На сервере
/etc/ssh/sshd_configконсоль
На клиенте
X — перенаправлять графический выводС — компрессия передаваемых данных
/etc/ssh/ssh_config
консоль
Далее выбор приложения, я это сделал через mc и запуск.
Испытания
1) Графическое приложение на клиенте действительно запустилось по ssh, в моём случае это был Qt Creator. Были небольшие ошибки.
2) Так же внутри программы всё выглядело как на сервере в частности проекты и даже компиляция с запуском сработала.
3) Теперь смотрим на сервере потребление процессора и самое главное сетевого трафика пока использовалось подключение по ssh.
4) А вот я запустил на серевере x11vnc и подключился к нему с клиента по krdc (vnc://192.168.1.2).
Пробелы в использовании сети возникали тогда, когда ничего не делал и на экране не было приложений меняющих на нём изображения, вроде того же системного монитора с обновляющимися графиками, я уж про видео не говорю.
Итоги
1) С одной стороны есть смысл запускать графические приложения по ssh в случае простого удалённого использования ресурса, про консольные думаю и так всё понятно.
2) Требования к клиенту по производительности остаются, если и не высокими, то не низкими.
3) Требования к серверу по производительности должны быть высокими.
4) Преимуществ запуска по SSH в том, что запускаются лишь те приложения, с которыми работаешь, но минус в том, что делать это нужно из консоли пусть и по mc.
5) А недостаток в очень низкой универсальности данного решения, так сказать очень узкая ниша применимости. Что делать если нужна десктоповая винда или ещё что-то не серверное, а то и кастомное. Получается переусложнение.
6) По трафику особого преимущества лично я не вижу, разве что по ssh не будет лишних открытых приложений, значит и трафика не будет при неактивности, а случайной активности тоже не будет.
Как по мне такое использование ssh не для обычных компаний, потому что не универсально и слишком сложно. А пользователем по идее должен быть любой человек, который вообще ничего не понимает кроме своей узкой области. Например, инженер со своим CAD пакетом и проброшенной видеокартой, или бухгалтер с виндой и 1C. Но и к программисту предъявляется слишком много требований, так как он может сидеть где угодно, в винде, гну/линуксе, макоси, андроиде и даже айфоне, но при этом его удалённое рабочее место не должно зависеть от фактора доступности ssh и набора всяких заумных команд.
Опять же я уже писал выше про удалённые рабочие места. Офисная машина не является удалённым рабочим местом, если в принципе физически доступна сотруднику, то есть он может прийти и сесть за неё, пнуть её ногой, отформатировать с флешки при загрузке и всё в таком роде.
V>Идея интересная, и я не про VPN, это всего лишь сеть поверх другой сети, непонятно, что она в данном случае даст.
Через VPN входишь в рабочую сеть и получаешь доступ ко всем нужным ресурсам. Куда уж проще-то?
V>По поводу SSH, у меня есть сервера на мобильном интернете, то есть к симкам привязан статический ip. Когда я их админю в консоли вижу задержку и время отклика нестабильно. Очевидно, что с GUI будет не лучше, а только хуже.
Какой еще GUI по SSH? Разве что буффер обмена прокинуть через X, для этого да, надо настроить X11Forwarding. Нормальный сценарий работы через SSH это обычное редактирование/сборки проекта на твоей рабочей машине удаленно. Зачем тебе для этого GUI-то, консоли же за глаза хватает? Ну разве что ты GUI-разработчик, тогда только страдать
KP>Через VPN входишь в рабочую сеть и получаешь доступ ко всем нужным ресурсам. Куда уж проще-то?
Можно просто зайти на сервер без частной сети.
KP>Зачем тебе для этого GUI-то, консоли же за глаза хватает?
Тогда вопрос, зачем удалённое рабочее место? Git и так всё синхронизирует как надо. Даже доступ в интернет не нужен, пока не соберёшься скинуть все коммиты.
Но помимо того, что на удалённых рабочих местах об оборудовании и софте заботится работодатель снимая это бремя с сотрудников, дело ведь ещё и в психологическом факторе.
Причём психологический фактор работает как на сотрудников, так и на работодателей. Как отметить, что человек пришёл на своё рабочее место и работает?
Да, сотрудники сейчас начнут заливать, что джентльменам нужно верить на слово. А, к примеру, ставить им на компьютер шпионское ПО лично я считаю в край оборзевшим решением.
К тому же так всё равно не абстрагироваться, не прийти в рабочий режим. Тот же домашний компьютер так и останется домашним сколько бы профессионального софта на него не было поставлено.
И опять же я всего лишь высказал своё теоретическое видение ситуации в ответ на вопрос как создать удалённые рабочие места. Представь, что тебе дали задание создать удалённые рабочие места для:
1) Программистов.
2) Бухгалтеров.
3) Конструкторов.
4) Дизайнеров
5) Консультантов.
И всё в таком роде. Как решить это задание?
А теперь добавлю условие, что сотрудников лишь в одной организации может быть несколько тысяч.
И ещё условие, сотрудники могут быть компьютерно неграмотными. Они как обезьяны смогут тыкать лишь на графические кнопки.
Программы для того и пишут, чтобы они упрощали, а не усложняли жизнь. Если у кого-то есть идеи получше, чем изложенные мной, то я бы почитал. Возможно в силу ограниченности знаний я что-то упускаю.
V>Можно просто зайти на сервер без частной сети.
Сервера часто недоступны из за пределов корпоративной сети.
V>Тогда вопрос, зачем удалённое рабочее место? Git и так всё синхронизирует как надо. Даже доступ в интернет не нужен, пока не соберёшься скинуть все коммиты.
Ускорение сборки как минимум. У меня проект собирается после rebase где-то 15 минут на рабочем компьютере в офисе и около 3 часов если дома. Сборочные кэши из за пределов корпоративной сети не самая быстрая штука, когда надо выкачать несколько гигов за раз.
V>Но помимо того, что на удалённых рабочих местах об оборудовании и софте заботится работодатель снимая это бремя с сотрудников, дело ведь ещё и в психологическом факторе.
IT-отдел выдает настроенный ноутбук/компьютер где всё просто работает. Какая разница дома или в офисе человек? У нас в другую страну подготовленные к работе ноутбуки высылали если человека уже наняли, а из за ковидлы прям сразу перевезти не удалось.
V>Причём психологический фактор работает как на сотрудников, так и на работодателей. Как отметить, что человек пришёл на своё рабочее место и работает?
Человеку платят за жопочасы или работу? Если работу — то никак не отмечать пришел ли. В конце недели, максимум месяца, будет ясно работал или нет.
V>Да, сотрудники сейчас начнут заливать, что джентльменам нужно верить на слово. А, к примеру, ставить им на компьютер шпионское ПО лично я считаю в край оборзевшим решением.
Зачем такое извращение? По результату более чем очевидно всё.
V>А теперь добавлю условие, что сотрудников лишь в одной организации может быть несколько тысяч.
У нас 1К человек, все удаленно, проблем вообще нет — все работают, продукт развивается.
KP>Ускорение сборки как минимум. У меня проект собирается после rebase где-то 15 минут на рабочем компьютере в офисе и около 3 часов если дома.
KP>У нас 1К человек, все удаленно, проблем вообще нет — все работают, продукт развивается.
Мы ходим по кругу, у вас сотрудники удалённые, а не рабочие места.
Ну так вот, qemu работает в Windows.
V>Почему удалённые места не захватили мир?
Не до конца понятно какую проблему вы пытаетесь решить? Где это можно применять?
Прикидывали ли какие накладные расходы придётся нести ради всех этих достаточно спорных плюсов?
Сравнивали ли с другими вариантами?
И почему вы считаете это будущим, а не прошлым?
AM>Не до конца понятно какую проблему вы пытаетесь решить? Где это можно применять?
Выше всё описано и несколько раз ещё пояснено. Но есть ещё один случай, который я не рассматривал, а именно ковид. Из старых проблем сложность найма сотрудника удалённо. Даже в этом случае зачастую нанимают в офис и только потом разрешают сотруднику работать удалённо. А что если сразу нанимать удалённо, но без шпионского по.
Ладно там DDoS или просто DoS, проделки конкурентов или просто вредителей, но сотрудник которого в глаза не видел может очень плохо обойтись с рабочим местом, потому и нанимают сначала в офис, а потом отпускают работать домой.
Применять всё это можно глобально. Фатальная точка отказа интернет, то есть ставить удалённые рабочие места можно будет только там, где он очень хороший.
AM>Прикидывали ли какие накладные расходы придётся нести ради всех этих достаточно спорных плюсов?
Очень и очень дорого, даже если начать можно с обычного компьютера это всего лишь пара сотрудников, а то и один, если не охота жертвовать эффективностью. Обычно корпораты торгующие решениями говорят, смотри мы делаем дешевле, даже если это не так. А это обычно не так. А я могу сразу сказать, что это дороже, чем тот же вариант как у kaa.python, где его наняли в офис, а он потом просто управляет машиной удалённо со своего локального рабочего места.
AM>Сравнивали ли с другими вариантами?
AM>И почему вы считаете это будущим, а не прошлым?
Ну, вообще это не я до этого додумался. Например, я пишу в запросе 'как создать удалённое рабочее место'.
Как организовать удаленные рабочие места для сотрудников
Во втором случае идёт пояснение.
Как работает виртуальное рабочее место.
Тема создана для обсуждения, а не для поучений, не для попытки что-то навязать или продать. То есть это я должен спрашивать, а что вы об этом всём думаете.
V>Здравствуйте, AntoxaM, Вы писали:
V>Применять всё это можно глобально. Фатальная точка отказа интернет, то есть ставить удалённые рабочие места можно будет только там, где он очень хороший.
Вы же понимаете, что это большое ограничение? К тому же не единственное.
А если пользователю для работы нужен браузер, в котором он открывает условные CRM и почту, то прослойка выглядит не нужной.
Так что слово "глобально" надо заменить и подумать, где можно и имеет смысл применять.
AM>>Прикидывали ли какие накладные расходы придётся нести ради всех этих достаточно спорных плюсов?
V>Очень и очень дорого, даже если начать можно с обычного компьютера это всего лишь пара сотрудников, а то и один, если не охота жертвовать эффективностью. Обычно корпораты торгующие решениями говорят, смотри мы делаем дешевле, даже если это не так. А это обычно не так.
Ок, хорошо, что понимаете, что это дорого.
Будут ли эти деньги удачным вложением? Мне кажется — не факт.
AM>>И почему вы считаете это будущим, а не прошлым?
V>Ну, вообще это не я до этого додумался. Например, я пишу в запросе 'как создать удалённое рабочее место'.
..
V> Рабочее место как услуга (англ. Desktop as a Service, сокр. DaaS) — модель распространения и эксплуатации программного обеспечения aaS, получившая известность в начале 2000-х годов и являющаяся логическим продолжением SaaS.
Т.е. услуге уже почти 20 лет, и это всё ещё будущее?
V> Физически доступ к рабочему месту пользователь может получить через локальную сеть или Интернет. В качестве терминала может использоваться ПК или ноутбук, нетбук и даже смартфон. Устройство доступа используется в качестве тонкого клиента и требования к
И всё равно оказывается железка пользователю нужна.
Обнажённое солнце (роман)
V>>1. Что такое удалённое рабочее место.
N>Обнажённое солнце (роман)
А что, например, в России прямо все друг с другом содействуют? И ещё не нужно забывать, что даже эти наши сообщения проходят за счёт появления интернета и интернет серверов. В противном случае мы бы не смогли общаться находясь в разных частях планеты. Так что плохого в удалённых рабочих местах?
V>Потому запомните, удалённый сотрудник и удалённое рабочее место не обязаны пересекаться.
а для чего эта каша? ты диссертацию на тему пишешь?
или ты работаешь в офисе или удалённо, всё остальное пофиг.
и пофиг вообще откуда, из дома отеля с какой части севта тоже пофиг
V>Почему удалённые места не захватили мир?
пинка в зад надобыло, вот падемия этот пинок и есть
V>Потому что большинство работодателей не верят в удалённые рабочие места. Они даже не понимают разницу между удалённым сотрудником и удалённым рабочим местом.
ну теперь за 2 года поверили, проверено практикой и работает отлично, местами вскрылись даже большие плюсы.
в минусе окажутся те кто офисные помещения сдают, ну чтож, всегда ктото проигрывает ктото выигрывает
vsb>Будущее удалённых рабочих мест это IDE в браузере. Настоящее удалённых рабочих мест это запуск локального ПО, работающего с удалёнными ресурсами. Запускать ОС удалённо и прокидывать ввод/вывод это тупиковый путь.
Тогда нужно нечто, что могло бы разворачивать ПО на машине клиента, в нашем случае на рабочем месте сотрудника. А потом эта штука должна ещё уметь накапливать изменения хотя бы на уровне файлов, и пересылать на сервер, когда интернет канал оказывается доступен. Таким путём пошли в git, но реализация слишком переусложнена в использовании. В конце концов база данных с возможностью децентрализации была бы лучше для массового потребителя, чем гиковские штуки с файлами определённого формата. Но тут нужно учесть, что мы просто говорим о том, что нужно ещё запрограммировать, а не просто установить готовое.
V>Тогда нужно нечто, что могло бы разворачивать ПО на машине клиента, в нашем случае на рабочем месте сотрудника.
Не нужно, всё ПО на сервере и в браузере. На рабочем месте сотрудника нужен браузер, который в венду нынче встроен.
V>А потом эта штука должна ещё уметь накапливать изменения хотя бы на уровне файлов, и пересылать на сервер, когда интернет канал оказывается доступен.
Тоже не нужно, интернет всегда доступен, а если не доступен, работать всё равно не получится. Хотя при желании сделать можно, браузер с оговорками позволяет.
vsb>Не нужно, всё ПО на сервере и в браузере. На рабочем месте сотрудника нужен браузер, который в венду нынче встроен.
А как к примеру работать в каком-нибудь специализированном софте? Например, инженеру нужен CAD. Здесь или передавай нажатия клавиш, получай видеопоток, или устанавливай CAD на локальном рабочем месте. Но во втором случае это уже не удалённое рабочее место, а локальное. Таким образом получаем девиз — мы работаем на локальных рабочих местах удалённо от работодателя, а не мы работаем на удалённых рабочих местах от нас самих. Не знаю, вот каапитон давит на ssh, но это нежизнеспособно для инженера. Что ещё? Никто не предложил альтернативы.
vsb>>Не нужно, всё ПО на сервере и в браузере. На рабочем месте сотрудника нужен браузер, который в венду нынче встроен.
V>А как к примеру работать в каком-нибудь специализированном софте? Например, инженеру нужен CAD. Здесь или передавай нажатия клавиш, получай видеопоток, или устанавливай CAD на локальном рабочем месте. Но во втором случае это уже не удалённое рабочее место, а локальное. Таким образом получаем девиз — мы работаем на локальных рабочих местах удалённо от работодателя, а не мы работаем на удалённых рабочих местах от нас самих. Не знаю, вот каапитон давит на ssh, но это нежизнеспособно для инженера. Что ещё? Никто не предложил альтернативы.
Уже есть CAD-ы, которые работает в браузере. Не нужно никаких видеопотоков и не нужно ничего устанавливать.
V>Здравствуйте, vsb, Вы писали:
vsb>>Будущее удалённых рабочих мест это IDE в браузере. Настоящее удалённых рабочих мест это запуск локального ПО, работающего с удалёнными ресурсами. Запускать ОС удалённо и прокидывать ввод/вывод это тупиковый путь.
V>Тогда нужно нечто, что могло бы разворачивать ПО на машине клиента, в нашем случае на рабочем месте сотрудника.
Зачем??? Гугол хром уже и так есть. Набирает выданный ему на бумажке адрес,
логинится там, и работает...
V> А потом эта штука должна ещё уметь накапливать изменения хотя бы на уровне файлов,
V> и пересылать на сервер, когда интернет канал оказывается доступен.
Это уже называется сетевая файловая система. Вон в виндах запилили "Автономные файлы" (или DFS)
для того. В линуксе как всегда, 20 лет делали coda fs и не смогли довести до рабочего состояния.
Это конечно тоже интересно, но уже на порядок больше мороки, сложно, дорого.
vsb>Будущее удалённых рабочих мест это IDE в браузере. Настоящее удалённых рабочих мест это запуск локального ПО, работающего с удалёнными ресурсами. Запускать ОС удалённо и прокидывать ввод/вывод это тупиковый путь.
Круто, я согласен. Но где хоть одна браузерная IDE, хоть бы уровня Vim? А мысль интересная.
Можно ли Vim собрать в webassembly? И только ввод-вывод ему из браузера дать. И ещё какой-то канал, чтоб
файлы вытаскивать с удаленной машины, и чтоб команды удалённые на ней выполнять. Только чтоб
с точки зрения Vim -- это были локальные файлы. Ну и экран на две части еще разделить, сверху Vim,
а снизу командная строчка и там что-то вроде ssh. Только чтоб все основные возможности Xterm были.
Наверное можно же. Смотрелось бы круто вообще. Ну само собой на хосте нужно что-то реализующее
вебсокет протокол. Или прокси на локалхосте же (где браузер), которая из вебсокет протокола всё
завернёт в ssh (ибо корпоративный прокси только его пускает). Ну и толерантность к разрывам должна быть.
Да и вообще окон а-ля xterm, как и VIm'ов нужно иметь возможность несколько открыть. Только окнами
должен управлять локальный window manager (т.е. это просто отдельные окна браузера должны быть).
fk0>Здравствуйте, vsb, Вы писали:
vsb>>Будущее удалённых рабочих мест это IDE в браузере. Настоящее удалённых рабочих мест это запуск локального ПО, работающего с удалёнными ресурсами. Запускать ОС удалённо и прокидывать ввод/вывод это тупиковый путь.
fk0> Круто, я согласен. Но где хоть одна браузерная IDE, хоть бы уровня Vim? А мысль интересная.
fk0>Можно ли Vim собрать в webassembly?
Охереть, всё уже почти сделано: https://rhysd.github.io/vim.wasm/
Терминал там через libvterm, но xterm.js никто не отменял (хотя при таком раскладе, наверное и не нужно).
Осталось ssh прикрутить как-то, ну и собственно сетевые файлы. Понятно, что теоретически
уже всё возможно, осталось только взять и сделать. Вон ssh тоже есть: https://github.com/stuicey/SSHy
через websocket прокси, разумеется.
Надо только всё это склеить вместе. Особенно ssh, чтоб он давал connection multiplexing и
ssh-agent. Думаю SSHy не очень годится, нужно как-то нормальный ssh-клиент в webassemlby
собрать и нужно ему какое-то минимальное окружение там внутри, POSIX-like. Не знаю насколько
это реально, но судя по Vim -- скорей да, чем нет.
Чем это отличается от обычного компа с линуксом? Только сетевой файловой системой.
Почему бы и дальше не работать в линуксе? Там там НЕТ сколько-нибудь приличной сетевой ФС.
Хотя нет, одна есть, NFS называется... Наверное можно как-то с помощью iptables, ipip,
прокинуть её через socks5 прокси, через ssh и пользоваться. Надо попробовать.
sshfs -- не предлагать. Кривая паделка, падает, съедает память и падает, дико тормозит.
Годится только для pet-проектов.
samba/cifs тоже не предлагать, в принципе так-то работает, но надо уметь выживать в условиях
разрыва связи (пусть и путем заморозки вима), с чем непонятно как, но скорей никак.
Ну само собой, нужно Vim настроить ещё, чтоб :grep был только через ssh, а не локально
(иначе чертовски медленно), чтоб все что через :shell вообще -- через ssh (видимо, вместо
sh подсунуть сразу ssh).
vsb>>Будущее удалённых рабочих мест это IDE в браузере. Настоящее удалённых рабочих мест это запуск локального ПО, работающего с удалёнными ресурсами. Запускать ОС удалённо и прокидывать ввод/вывод это тупиковый путь.
fk0> Круто, я согласен. Но где хоть одна браузерная IDE, хоть бы уровня Vim?
https://vscode.dev/
Вообще самая крутая это Github Codespaces, но они пока в закрытом режиме.
Ну и это только ростки. Сейчас это активно развивается. Intellij Idea в браузер уже наметилась. Думаю, в ближайшие лет 5 будет много интересного в этой сфере.
Лично я жду порта линукса в wasm. Чтобы это была полноценная архитектура с точки зрения ядра. Чтобы были драйверы для всех поддерживаемых API. Чтобы можно было Fedora установить прямо в браузер.
vsb>Здравствуйте, fk0, Вы писали:
vsb>>>Будущее удалённых рабочих мест это IDE в браузере. Настоящее удалённых рабочих мест это запуск локального ПО, работающего с удалёнными ресурсами. Запускать ОС удалённо и прокидывать ввод/вывод это тупиковый путь.
fk0>> Круто, я согласен. Но где хоть одна браузерная IDE, хоть бы уровня Vim?
vsb>https://vscode.dev/
Не работает на двух разных компах:
Visual Studio Code
Fatal Error Please check Developer Tools
И на телефоне то же самое. Там в логах что-то с микрософтовского облака прогрузиться не может.
vsb>>https://vscode.dev/
fk0> Не работает на двух разных компах:
fk0>Visual Studio Code
fk0>Fatal Error Please check Developer Tools
fk0> И на телефоне то же самое. Там в логах что-то с микрософтовского облака прогрузиться не может.
Хз, только что на айфоне открылось.
V>Почему удалённые места не захватили мир?
потому что есть такая штука как network latency (конечная скорость света, бессердечная сволочь), и keyboard latency и люди — забавные создания — очень к нему чувствительны.
примерно поэтому мир не захватила google stadia и тихонько умирает.
V>
3. Преимущества удалённых рабочих мест.
Про недостатки не сказано. Самый основной недостаток -- пинг в сотни мс, потому, что траффик
с "удаленного" ноутбука на стационарный комп под столом может идти через Лондон.
V>
3) Совместная работа для удалённых сотрудников.
V>1) Это может быть как слежение менеджером, тимлидом или уборщицей за сотрудниками в целях понимания их эффективности.
V>2) Совместное подключение разработчиков к одной машине для реализации практик парного программирования, обмена опытом, обзоров кода.
V>3) Ну или не кода, в конце концов удалённо могут работать бухгалтеры, инженеры и прочие, ведь пробрасывать можно разное оборудование, от видеокарт до специализированных портов.
Достаточно скайпа или чего-то вроде. С чатиком, возможностью устроить групповой звонок и пошарить экран.
V>1) Один сотрудник может не знать о других, следовательно не предоставит компромат на компанию.
V>2) Маски шоу врываются в пустые офисы и не могут парализовать работу компании изъяв оборудование.
Врываются в серверную о простреливают жесткие диски! Придумать можно что угодно.
Например, приходить домой к удаленным сотрудникам и локально бить их резиновыми дубинками.
Сами разбегутся.
V>3) Люди территориально сидят по всему миру, они функция, а не физическое тело.
А деньги как им перечислать? Это самая основная проблема. А то бы уже все побежали
удалённо кто куда. А главное физически переехали в места где жить дешевле и лучше.
V>4) Нанимаешь сотрудника как винтик и так же его увольняешь.
Палка о двух концах. Сотрудник так же в один день пропадает т.к. нашел работу где платят
немного повыше. В итоге получается как с "фрилансом", о котором много разговоров, но денег нет.
Всё скатывается к почасовой оплате с нано-суммами и идиотскими проектами.
Нормальному работнику, как и нормальному работодателю нужна какая-то уверенность, что
не будет беготни.
V>
4. Решения для создания удалённых рабочих мест.
V>1) VMWare vSphere ESXiV>2) Microsoft Hyper-V Server
V>3) ProxMox VE (KVM)
V>4) OpenNode (щито это?)
Это всё не нужно. Нужна какая-то форма VPN, какой-то аналог RDP, VNC, ssh, etc...
Какой-то аналог скайпа. Всё. В принципе можно наверное даже без VPN.
Удаленному работнику скорей нужна удаленная машина в сети организации, и не жалкая
виртуалка, а что-то на чем можно работать. Ну т.е. гигабайты и гигагерцы. Можно
в серверной стойке, это не принципиально. Можно раздел на мейнфрейме. Можно
даже виртуалку, но это вполне может быть и линуксовый контейнер, а то и просто
логин на общем сервере. Наверное последнее самое простое.
V>
Почему удалённые места не захватили мир?
V>Потому что большинство работодателей не верят в удалённые рабочие места. Они даже не понимают разницу между удалённым сотрудником и удалённым рабочим местом.Как решить следующие проблемы:
1) я хочу работать на фирму из США, т.к. фирма в США может платить больше, с одной стороны,
а с другой мне платить меньше, чем местным;
2) как при этом решить дилемму, что индусам платить ещё меньше;
3) как я буду получать деньги? документально оформить "трудоустройство" практически
не представляется возможным по разным причинам (местное законодательство, языковой
барьер и т.п.)
4) как "работодатель" будет платить зарплату, верней как она у него будет проходить
через бухгалтерию?
4) как "работодатель" может быть уверен, что я завтра не пропаду без вести;
5) а я могу быть уверен, что работодатель не найдет индуса подешевле.
6) как "работодатель" может понять, что со мной вообще связываться можно, т.к.
через монитор нифига не видно и будет же 90% кидалова при таком "трудоустройстве"
(будут специально обученные люди ходить собеседоваться, и потом совершенно другие
индусы работу работать).