Переходим с Linux на Windows на рабочей машине

Пролог

Холивары на тему сравнения различных ОС были, есть и будут есть всегда. Правда в том, что каждый склонен выбирать то, что ему больше всего нравится. При этом критерии у каждого разные (этого часто не понимают) — что важно для одного — мелочь для другого. ОС — дело интимное личное.
Однако, бывают ситуации когда добровольный выбор той или иной ОС невозможен. В этой статье речь пойдет о рабочих машинах, об ограничениях и о том что делать если нельзя но очень хочется.

Начало

Большие проекты часто обрастают целой «инфраструктурой поддержки» в виде второстепенных программ призванных настроить/обеспечивать правильную работу главного проекта. Помимо этого, большой проект со временем становится привязанным к определенным версиям библиотек/компонентов/компиляторов и т.п. Чем сложнее проект, чем дольше он в разработке и чем больше команда разработчиков — тем крепче закрепляется требуемая конфигурация программного обеспечения.
Со временем вырабатывается определенная «инструкция по использованию», точно следовать которой — единственный путь заставить древнего монстра работать. Это накладывает достаточно большое ограничение на выбор инструментов разработки, включая ОС.

Эта статья построена на основании личного опыта присоединения к поддержке большого и относительно старого Ruby on Rails проекта, поэтому некоторые моменты будут рассматриваться именно с этой точки зрения (что не мешает рассматривать статью без привязки к языкам программирования/фреймфоркам).

Ситуация

В моем случае проект можно было поднять только на Linux (Debian-based) или Mac. Дело в системных зависимостях некоторых гемов (Gems) Ruby on Rails. Путь на Windows был закрыт совершенно. Попытки «А может все же…?» ни к чему так и не привели.
Ноутбук с легальной копией Windows 8 постоянно заставлял возвращаться к желанию «пересесть на винду», и в один прекрасный момент терпение лопнуло.

Решение

Обдумав список личных требований к рабочему месту, решил что от Windows мне нужен сам Windows, а от Linux мне нужна консоль (чертовски удобно же!) и возможность поднимать все тот же требуемый проект.

После некоторых сомнений и раздумий было решено попробовать такую схему:

Как видно, ядро среды составляет Ubuntu на виртуальной машине. На нем поднят Samba сервер (и подключен в Windows как сетевой диск), поднят RoR сервер (доступен с Windows по IP VM), ну и Bash. Такая конфигурация позволяет настроить проект на работу в привычной среде, вместе с тем открывая три канала взаимодействия с хост окружением. Для себя я это назвал LiW (Linux inside Windows).

SMB служит для создания сетевого диска в среде Windows. Метод проб и ошибок показал, что это самый надежный и быстрый (!) способ расшарить папку на виртуальной машине для доступа к ней из хост-ОС. IDE запущен в среде Windows, в нем открывается сетевая папка — и готово! Скорость работы значительно ниже чем на реальной Ubuntu машине, но все равно остается вполне удовлетворительной и становится заметной только когда IDE начинает индексировать проект.
Samba поднимается под Ubuntu без всяких проблем — гугл знает как это делать.

Поскольку речь идет о web-разработке, то вторым важным инструментом является браузер. Он так же работает в среде Windows, обращаясь на IP виртуальной машины. Для удобства прописаны алиасы в hosts. Скорость работы отличная, проблем никаких.

Терминал — особо полезная вещь для разработчика. В этом плане хотелось сохранить всю мощь и удобство консоли Linux. Велосипед изобретать не пришлось — тщательный выбор и настройка SSH клиента для Windows позволил получить отличный уровень комфорта при работе с консолью.

Детали

Виртуальная машина

Я для себя выбрал WMWare из-за адекватного сетевого взаимодействия между хостом и гостем. Сетевой адаптер виртуальной машины работает в режиме NAT. Одно это позволяет обращаться к виртуальной машине по IP-адресу из Windows. К примеру, сделать то же самое с VirtualBox так и не получилось — требовались настройки проброса портов, а вникать желания не было (может у Вас все получится, это лишь мой опыт).

Виртуальная машина настроена на автозапуск при старте Windows. Для этого в Автозагрузку помещен следующий .bat скрипт:

"C:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe" -T ws start "C:\Users\user\Documents\Virtual Machines\Ubuntu\Ubuntu.vmx" nogui 

Ключом к успеху тут служит параметр nogui — с ним виртуальная машина сразу запускается в фоновом режиме. Подождали минутку и можно начинать работать. На практике виртуальная машина так все время и работает в фоновом режиме — нет никакой необходимости прямого к ней доступа. От этого и создается ощущение что все работает прям под Windows (чего я и добивался).

После перезагрузки компьютера (у меня это раз в неделю) — необходимо переподключить сетевой диск.

Попытка использовать встроенные в WMWare расшаренные папки не обвенчались успехом — работает адски медленно и нестабильно. Есть тут правда одна интересная возможность — подключить в WMWare реальный физический раздел/диск и обращаться к нему же из Windows, но я это еще не пробовал (отпишитесь пожалуйста в комментариях кто настраивал).

Терминал

Опять же после долгих проб выбрал для себя в качестве SSH клиента замечательное приложение XShell 4. Оно бесплатно для домашнего и школьного (мой выбор) использования.

Почему именно XShell? Мне в нем понравилась система вкладок, система автоматической сортировки нескольких окон в пределах рабочего стола (использую несколько мониторов, один полностью выделен под терминал). На скриншоте — вариант с отключенными менюшками, осталась только панелька вкладок.
И самый главный момент — можно настроить поведение копирования-вставки сравнимое с терминалом Linux.

И не забыть про хоткеи копирования-вставки:

В итоге получаем такое привычное линуксовое поведение — выделяем в консоли текст (он сразу копируется в буфер обмена), щелкаем среднюю кнопку мыши, и текст вставляется на место курсора. Супер!

Git

Вся работа с гитом происходит из XShell. Была отдельная проблема с IDE (RubyMine) — при попытке запуска встроенного git клиента он блокировал работу гита в виртуальной машине. Это происходило из-за того что виндовый гит подключался в ту же папку (сетевой диск) и прописывал туда свой lockfile. От чего линуксовый git уже не мог запуститься. Поскольку IDE любит периодически подергать git для индексации изменений, то работать в таком режиме невозможно.
Выходом из ситуации было написание крошечного псевдо-гита на Ruby — ssh-git.exe который принимает параметры командной строки, создает SSH подключение на виртуальную машину, переходит в нужную папку и запускает там линуксовый гит с теми же параметрами. Результат выполнения возвращается в неизменном виде в IDE. Аналог такого решения в интернете не нашел, хотя искать было дольше чем написать самому.

require "net/ssh" Net::SSH.start("192.168.113.129", "user", :password => "pass") do |ssh|   result = ssh.exec!("cd Developer/main && git #{ARGV.join ' '}")   puts result end 

(Ruby скрипт скомпилирован в exe с помощью OCRA).

Заключение

Читатель справедливо может заметить, что слишком все это сложно и костылисто. Да, так есть. Но если подойти к делу с долей терпения и изобретательности, то результат получается отличным. Лично я не потерял абсолютно никакой функциональности по сравнению с Ubuntu. Скорость работы виртуальной машины (ноутбук на Intel Core i7-3630QM) приближается к реальной — разницу можно почувствовать только в синтетических тестах.

Плюсы

• Windows GUI
• Возможность запуска Windows приложений (Photoshop, IE, etc.)
• Более стабильная работа системы чем с Ubuntu (личный опыт)
• Возможность гибкой настройки под свои нужды
• Отличная ситуация с драйверами устройств (использование трех мониторов без каких-либо плясок с бубном)
• Возможность использовать Remote Desktop для работы из дому (по ощущениям намного комфортнее чем VNC)
• Возможность легко забекапить и восстановить образ настроенной виртуальной машины
• Общее ощущение — комфорт Windows и мощь Linux в одном флаконе. Идеальная ОС 🙂

Минусы

• Низкая пропускная способность Samba-сервера. Ощущается моментами и больше зависит от используемой IDE
• Необходимость допиливать некоторые моменты руками (как в моем случае получилось с git)
• Необходимость дополнительных действий перед выключением компьютера (сначала выключить виртуальную машину) и после запуска (подключить сетевой диск), хотя при большом желании и это можно автоматизировать.
• Не подходит, если есть необходимость запускать GUI Linux приложения.

P.S.. Если сравнивать, то мне LiW конфигурация нравится намного больше чем к примеру Ubuntu+Wine для запуска Win32 приложений. В случае с Wine мы получаем недо-винду, но в случае с LiW — и винда нормальная и линух настоящий. Так что несмотря на непривычность решения — оно действительно получается полным в плане функциональности.