Web разработка в Windows под Linux?

Раньше сидел на Windows, в данный момент использую Ubuntu для веб-разработки.
В связи с ограничениями Linux, а именно:
— нет поддержки SLI Nvidia для мобильных видеокарт
— ПО на виндовсе все же лучше (Excel, Photoshop, Premiere Pro и т.п.)
— игры на ОС Windows
— личные предпочтения
решил обратно вернуться на Windows.

Проблема в том, что я сильно привык к Linux, и на моем VPS тоже стоит Ubuntu. И теперь я не знаю даже, как переехать на Windows, но при этом сохранить преимущества Linux в виде: консоли, простой настройки web-сервера и т.п.

Есть варианты использовать VirtualBox, однако, мне не совсем хочется работать во втором окне с пониженной производительностью компьютера. Слышал про Vagrant, но так и не понял, как настроить с конфигом, описанным ниже.

В общем я бы хотел иметь такую схему работы:

Windows — основная ОС. На ней будут такие программы как PhpStorm, SublimeText3, браузеры, консоль и т.д.
Ubuntu — web-сервер и другоеПО (PHP, nginx, mysql, git и т.д.), управляется консольню на Windows.
И между этими двумя ОС будут общие папки, файлы, которые редактируются на Windows.
Также должна быть возможность проводить тестирование на Behat, и как-то эмулировать поведение браузеров на Windows.

В общем, ребята, тема довольно избитая. Подскажите, пожалуйста, кто как решил такую дилемму?

• Вопрос задан более двух лет назад
• 2647 просмотров

Николай,
. Ведьмак 3, DooM (2016). Battlefield 1, PubG, GTA V, FarCry, fallout, .

Вы, похоже, вообще не в теме, лишь бы яблочко защитить.

Anton Mashletov, файлы пробрасывать не нужно.
там общая файловая система

запустить да, нужно вручную один раз в день.
если вы линуксоид, то простейший скрипт вас не напугает

Весь линуховый софт подымаете на VPS. А чтобы были общие папки и пр. — заводите между виндой и VPS VPN.

ЗЫ: На самом деле, если бы не игры — я бы давно сделал дома такую же схему как на работе сейчас — хостом является линух, в нем KVM-виртуалка с виндой. Недостатком этого метода является уродская эмуляция видео в qemu и, как следствие полный облом с играми. Есть еще вариант пробросить видюху, но это требует поддержки железа и мозгов, как у марсианина.

Не знаю можно ли советовать такое, у меня так исторически сложилось и 7 винда держит.

1. Виртуалбокс с дебианом без гуи
2. Папка с папками проектов в винде
3. Гит тоже под виндой
4. Односторонний синхронизатор, вот этот — dklab.ru/lib/dklab_realsync Папка с папками проектов мапится на папку в виртуалке, на которую смотрит вебсервер. Синхронизует мгновенно, пока переходишь из иде в браузер файл уже залит 100%. Для каждого проекта нужно прописывать список игнора для этого синхронизатора, в него попадает все самогенерящееся — кэши, логи, папка вендор, файлы композера (композер используется на стороне линукса), статика и тд. В обратную сторону приходится прокачивать вручную. Для этого приходится замапить проект в шторме на его папку в виртуалке. Двухсторонняя синхронизация невозможно никаким способом, шторм уходит в вечную переиндексацию. То же самое происходит если примонтировать папку виртуалки в винду, одно малейшее изменение вызывает переиндексацию, а по сети она замедляется раз в 50. Шаред фолдерс тоже не подходят, с ними удобно было, но тормозят адски. То что делается 100 мс, с ними может занять 2.5 сек. Какая-то проблема из-за разницы нтфс и экст4, что-то оно там налету постоянно конвертирует. Согласно интернету не излечимая. В ходе изучения проблемы все свелось к этому синхронизатору. Там на странице тоже описано почему так.

Работающая схема, но добавляет неавтоматизируемые вещи к ритуалу создания нового проекта.

А вообще думаю второй комп лучше всего решил бы эту проблему))

Добавлю свои 5 копеек.

1. «Есть варианты использовать VirtualBox, однако, мне не совсем хочется работать во втором окне с пониженной производительностью компьютера. Слышал про Vagrant, но так и не понял, как настроить с конфигом, описанным ниже.»

Сравнивать Virtual Box и Vagrant — не правильно. Vagrant — это по сути «автоматизатор» подъема виртуалки. Он читает вагрант файл, качает нужный образ, запускает Virtual Box (или другой провайдер на ваше пожелание), накатывает образ и запускает ОСь. После этого выполняет sh скрипты, написанные вами-же в вагрант файле, тем самым готовя виртуалку к работе. И собсно всё. Вагрант удобен когда вам необходимо использовать одну и ту же конфигурацию на разных машинах. Вы просто посылаете вагрант файл в несколько килобайт другому человеку, вместо того чтобы шарить виртуалку. Еще есть удобство когда самому нужно часто перенакатывать новый инстанс.
Вывод: Проблему второго окна вагрант не решит. Но есть вариант, см. пункт 2.

2. У меня на работе винда десятка, проект крутится на виртуалке. Работать во втором окне мне тоже не очень доставляло, поэтому я делаю так:
— Запуск виртуалки происходит headless, тобишь в фоне.
— Между виртуалкой и хостом пошарена папка с проектом
— Для разработки я использую IDEA. У нее есть встроенный терминал. Я думаю PhpStorm должен иметь такую же фичу.
— Подключаетесь к виртуалке по ssh и вот вам щщастье )

— Гонять файлы при необходимости можно тоже через терминал и scp или поставить WinSCP.

Надеюсь, был полезен.

вот как оказывается ссш в шторме включается www.jetbrains.com/help/phpstorm/settings-tools-ssh. надо было галочку поставить на плагине) всю жизнь думал, что в нем только несчастная локальная консоль.

для винды очень удобная xshell. сейчас посмотрел, вышла новая версия (6), в ней в бесплатном варианте ограничение 4 вкладки на окно, это не годится для использования. лучше ставить 5-ю.

Visual C++ for Linux Development: Практика использования для Windows разработчиков

Так получилось, что за достаточно долгую карьеру Windows и Embedded разработчика судьба свела меня по серьезному с Linux всего лишь несколько месяцев назад. Нужно было написать не очень сложную консольную программу. На тот момент все мои знания о Linux были взяты из курса по операционным системам в вузе (10 лет назад). Но Stackoverflow, google и опыт позволили достаточно быстро справиться с задачей. В итоге все было написано в Visual Studio Code под Ubuntu 14.04. Правда, приложение под Linux являлось только лишь небольшим клиентом для Windows сервера. Поэтому результат не очень удовлетворял меня, так как был оторван от основного проекта в Visual Studio. И только сейчас я смог перенести код в основной проект с помощью Visual C++ for Linux Development. В процессе мне пришлось решить несколько сопутствующих проблем. Об этом я рассажу под катом.

Итак, Visual C++ for Linux Development — это расширение для Visual Studio, позволяющее писать код в привычной многим IDE под Windows, а отлаживать его прямо в целевой операционной среде — Linux. При этом используется GCC и Remote GDB Debugger. Более подробно о расширении можно прочитать в блоге разработчиков или в переводе на хабре.

Инструкции того, как установить, запустить, настроить и т.д. можно найти по ссылкам выше. У меня с этим не возникло никаких проблем. Вопросы начались со стороны Linux системы. Напомню, что я использую Ubuntu 14.04 LTS и дальнейшее изложение пойдет именно про нее. Если кому интересно, я использовал образ для VirtualBox с сайта osboxes.org.

Также, прошу сильно меня не ругать, я все-таки в Linux далеко не гуру. Лучше подскажите, если что-то можно сделать более оптимальным путем.

Отладка первой программы

Перед тем, как использовать удаленную отладку, нужно установить несколько компонентов на Linux системе. Как указано в инструкциях по ссылке выше, это можно сделать, выполнив в командной строке следующее:

Вызвать терминал в Ubuntu можно комбинацией клавиш Ctrl+Alt+T.

Я не помню, запускается ли все это хозяйство сразу или нет, по этому на всякий случай можно перезагрузиться.

Если все сделано правильно, то будет открыт порт 22. Проверить это можно используя команду nmap .

Но сразу подключиться из-под Visual Studio у меня не удалось, так как система почему то не пускала меня под единственным пользователем. Пришлось создать другого. Это можно сделать в System Settings → User Account.

При этом, не забыв нажать кнопку Unlock в верхнем правом углу.

Настроить подключения в Visual Studio можно в окне Tools → Options

Теперь можно запустить и отладить тестовый проект.

При этом в Ubuntu будут скопированы исходники и собранный файл программы (если это не отключено в настройках проекта). Все это можно будет найти в папке /home/ /projects.

В моем случае получилось вот так:

Запустить программу в самом Linux можно из консоли:

Теперь вроде бы можно начинать работать. Я перенес исходные файлы в Visual Studio и… ничего у меня не скомпилировалось. Оказалось, что проекту не достает .h файлов из include directories.

Подключаемые файлы

Вместе с Visual C++ for Linux Development устанавливается и множество заголовочных файлов. Их можно найти тут:

Но моему проекту этого не хватило.

В блоге разработчиков по этому поводу сказано следующее:

В будущем эту проблему обещают решить, ну а сейчас крутитесь как хотите. Там же приведен пример с копированием директории всей /usr/include с помощью PuTTY.

Но мне такой путь не нравится. Лично я предпочитаю расшарить папку с заголовочными файлами. Список директория для поиска include файлов можно посмотреть, выполнив в консоли команды

Мне хватило папки /usr/include .

В случае с моей версией системы, перед тем как расшарить данную папку, нужно перевести ее во владение текущему пользователю. Делается это командой sudo chown -R osboxes:test ‘/usr/include’ .

После этого можно открыть доступ к папке. Как это сделать написано тут.

После этого, сетевые пути можно прописать в Visual Studio как Include Directories.

Такой подход имеет преимущество в виде того, что вы будете работать всегда с оригинальными заголовочными файлами и вам не нужно будет ничего синхронизировать. С другой стороны, будут проблемы при переносе разработки на другой компьютер. Также, как я уже писал, я работаю с Ubuntu, установленной на виртуальной машине на моем компьютере. При такой конфигурации, проблемы с безопасностью уходят на второй план.

Но в других конфигурациях, действия, описанные мной выше, могут быть запрещены.

Таким образом, проблему синхронизации заголовочных файлов нужно решать исходя из условий работы. Тут выбор остается за вами.

Дополнительные команды компилятора и линкера

Заголовочные файлы стали видны и компиляция прошла успешно. Но вот слинковаться проекту не удалось. Дело в том, что я использую потоки и заголовочный файл «pthread.h». Для того, чтобы линкер увидел библиотеку pthread, нужно использовать опцию -pthread или -lpthread.

Для этих целей в Visual C++ for Linux Development есть специальная настройка:

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

Если в место g++ написать g++ -pthread, то получится правильная строка линкера:

Тот же трюк срабатывает и для компилятора.

Запуск отладки с правами администратора

Теперь все скомпилировалось и слинковалось. Однако для работы программы нужны повышенные права, так как она открывает файл устройства ввода. Соответственно, отладку также нужно запускать с правами администратора. Сейчас в Visual C++ for Linux Development эта опция не реализована, но есть одно решение.

Можно повысить в правах gdb и gdbserver командами

Такой совет можно найти в комментариях в посту в блоге разработчиков.

Этот трюк работает, но он не безопасен. По сути, вы отдаете свою систему любому, кто подключается к gdbservr. В моей конфигурации это не страшно, так как все запущено на одном моем компьютере, но в других условиях нужно быть очень аккуратными с такими действиями.

Копирование дополнительных файлов

И остался последний момент. Моя программа читает настройки из текстового файла. Он является частью проекта Visual Studio и при компиляции должен копироваться в папку с исполняемым файлом.

Это можно также сделать в настройках проекта:

Чтобы просто скопировать файл, как остальные исходники, его можно добавить в поле Sources To Copy: @(SourcesToCopyRemotely);config.txt

А скопировать его в другую директорию можно с помощью Additional Sources To Copy.

Формат этой настройки
fulllocationpath1:=fullremotepath1;fulllocationpath2:=fullremotepath2
и т.д.

В моем случае такая строка выглядит так:

Все бы хорошо, но и тут у меня возникли проблемы.
Дело в том, что макрос $(RemoteOutDir) раскрывается в путь, начинающийся с символа «

Судя по всему, этот путь завязан с этой настройкой:

Так вот, при компиляции все работает хорошо. Но вот при копировании файлов почему то

воспринимается не как root директория, а просто как имя папки. То есть создается папка с именем «

Справиться с этим мне так и не удалось, поэтому я просто копировал файл config.txt вручную. Правда, для этого пришлось опять использовать изменение прав на папку:
sudo chown -R osboxes:test ‘/home/test’

Что в итоге

Лично я могу сказать, что Visual C++ for Linux Development extension мне помог. Несмотря на все проблемы и пару багов, он позволил мне быстрее и эффективнее решить задачу, связанную с разработкой под Linux.

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