Использование графических интерфейсов, USB-подключений и Kubernetes
Введение
Как вы, возможно, знаете из моих предыдущих постов, я склонен использовать множество сред разработки и экспериментировать с несколькими различными технологиями. Я пишу код для Linux, Windows и Mac на разных языках, в основном C/C++ с SYCL, Golang, Python, JavaScript и Java. Я также использую такие технологии, как Kubernetes, и балуюсь технологиями искусственного интеллекта, такими как TensorFlow, PyTorch и Intel Distribution of OpenVINO.
Я всегда заинтересован в упрощении кросс-платформенной разработки, потому что у каждого из нас никогда не бывает достаточно времени. В этом посте я опишу некоторые из своих быстрых опытов работы с подсистемой Windows для Linux (WSL). Короче говоря, в основном он работает отлично, иногда мы можем использовать обходные пути, чтобы заставить его работать достаточно хорошо, а иногда нам может потребоваться загрузиться в Linux.
Прежде чем мы зайдем слишком далеко, я бы порекомендовал, если вы используете WSL в Windows, получить последнюю версию из Магазина Microsoft, так как это устранило для меня некоторые проблемы, связанные с использованием CMake и некоторым другим странным поведением. Просто найдите WSL и установите подсистему Windows для предварительной версии Linux ниже.
Мне показалось странным, что его нет наверху, но если вы прокрутите немного вниз, вы найдете его. Быстрый совет: мне пришлось воссоздать среду WSL, чтобы изменения заработали на мне.
Предполагая, что вы не настроили среду WSL после этого, вы можете следовать любому руководству по настройке WSL (несколько ссылок на них ниже). Для справки, системы, которые я использую для этого поста:
- Ноутбук HP Envy 16 с процессором Intel Alder Lake Core i7-12700H, 32 ГБ памяти DDR4, графическим процессором Intel Arc a370m, Windows 11 Pro
- Alienware R13 с Intel Alder Lake Core i9–12900KF, 64 ГБ DD5, графический процессор NVIDIA GeForce 3080Ti, Windows 11 Pro
Что просто работает?
Основы
Если вы просто пишете код командной строки, сценарии или используете что-то вроде блокнота Jupyter, это прекрасно работает. Мои коды на C++, Python и Golang компилируются и работают точно так же, как в Linux. Conda, Tensorflow и PyTorch устанавливаются и работают.
Если вы хотите использовать некоторые простые инструменты, вот несколько ссылок, которые могут помочь вам начать работу:
Настройка WSL, VSCode и Intel oneAPI Base Toolkit
Программирование GPGPU на графическом процессоре Intel Arc
Kubernetes (для небольших систем)
Раньше я использовал K3 и MicroK8, но не был уверен, что они будут работать сразу после распаковки. Я был очень доволен тем, что установка K3s на WSL с использованием 20.04 Ubuntu была такой же простой, как и в Linux.
- убедитесь, что systemd настроен в WSL
- Установите K3s с https://k3s.io/ и запустите
sudo k3s server
- Установите kubectl, используя
sudo apt get kubectl
- убедитесь, что kubectl может использовать kubeconfig
/etc/rancher/k3s/k3s.yaml
Это небольшая часть того, что нужно разработчикам, и я не смогу охватить все, что работает хорошо, но в большинстве случаев WSL чрезвычайно прост в использовании.
Что работает с помощью?
графические интерфейсы
WSL2 — это огромный шаг вперед по сравнению с оригинальным WSL, поскольку в нем добавлена поддержка графических интерфейсов. Для некоторых вещей, которые я тестировал, это просто работало из коробки. Например, создание простого окна OpenGL и рендеринг простой сцены прекрасно работают. Единственная проблема, с которой я столкнулся, заключалась в том, что самая высокая версия OpenGL, поддерживаемая слоем WSL DirectX, — 3.3.
Мой второй тест состоял в том, чтобы проверить, будут ли работать наши инструменты Intel с графическим интерфейсом. Когда я попытался запустить графический интерфейс Intel VTune Profiler, я столкнулся с этой проблемой:
tonym@HPEnvy:~$ vtune-gui vtune-gui: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory
После установки некоторых библиотек я понял, что причина проблемы в том, что приложение ожидало установки GTK+ в системе. Следующие команды позволили мне запустить графический интерфейс Intel VTune Profiler в WSL:
> sudo apt install libnss3-dev > sudo apt install libatk1.0–0 > sudo apt install libatk-bridge2.0–0 > sudo apt-get install libgtk-3-dev
Самое замечательное в том, что я делаю это через WSL, это то, что теперь я могу использовать графический интерфейс для таргетинга моего приложения Linux в моей файловой системе WSL и запуска моей рабочей нагрузки.
Честно говоря, эта последняя проблема не является ограничением WSL. К сожалению, это очень распространенная проблема, с которой вы можете столкнуться, когда разработчики графического интерфейса Linux предполагают, что для их приложений существуют определенные библиотеки платформы.
Подключения USB-устройств
Когда я начал тестировать с помощью USB-устройства, простой рабочий процесс подключения моего устройства к машине изначально не работал. Конечно, это имеет большой смысл, поскольку для этого требуется сопоставление соединения через уровень виртуальной машины.
К счастью, есть способ включить устройство, подключенное через USB, с помощью проекта с открытым исходным кодом USB/IP. Microsoft задокументировала требования и способ настройки этой библиотеки для WSL, что позволило мне взаимодействовать с устройствами. Приятно иметь простые решения общих проблем!
VPN
Если вам требуется корпоративная VPN для работы, может быть очень сложно подключить экземпляр WSL к Интернету при использовании VPN. Есть несколько обходных путей, но официальный и неофициальный обходной путь можно найти здесь.
Что не сработало?
K3s с поддержкой графического процессора
К счастью для меня, есть только одна вещь, которую я пробовал, которая не сработала, и, возможно, я просто не знаю, как ее правильно настроить. Виновник запускает Kubernetes с поддержкой GPU. Я нашел некоторые ресурсы, которые предполагали, что вы можете заставить его работать, но я не смог заставить его работать.
WSL и Docker (или другие среды выполнения контейнеров) отлично работают из коробки. Единственный вариант использования, который у меня есть для этого, действительно нишевый; если вы хотите запустить рабочий процесс контейнера с поддержкой графического процессора, но хотите сделать это через K3s вместо другой среды выполнения контейнера. Это, вероятно, не имеет смысла, если вы не занимаетесь разработкой Kubernetes или не пытаетесь использовать развертывание Kubernetes.
Насколько я понимаю, WSL использует свой драйвер DirectX Linux для взаимодействия с базовыми графическими процессорами, и это может быть доступно для Kubernetes. Я не нашел простого способа сделать это. К сожалению, мой вариант использования был еще более узким; Я возился с реализацией конкретного подключаемого модуля устройства Kubernetes.
В конце концов, я просто запускал Linux в системах, когда мне нужно было это сделать.
Заключение
WSL отлично работает примерно для 95% того, что я делаю, и, хотя Linux установлен на всех моих системах, мне очень редко приходится загружаться в родной Linux. Это экономит мне значительное количество времени при кроссплатформенной разработке, и это здорово, так как мне не нужно тратить полдня на то, чтобы смотреть на загрузочный экран BIOS.
У этого также есть некоторые дополнительные преимущества, такие как возможность запуска некоторых из моих кроссплатформенных инструментов, таких как Python, в ОС, которую я предпочитаю. Вроде мелочь, но почему-то мне нравится печатать ls
вместо dir
. В общем, я считаю WSL огромной победой для моей производительности, и я предполагаю, что если вы читаете это, вы, вероятно, согласны (или вы хотите добраться до точки, где вы согласны 😊).
Want to Connect? If you want to see what random tech news I’m reading, you can visit me on Twitter.