유닉스/MS 윈도우

 


1. 개요
2. Xenix
3. SUA
4. Cygwin
5. Windows Subsystem for Linux (WSL)
5.1. WSL 1
5.2. WSL 2
6. 기타


1. 개요


데스크탑 PC의 운영체제로는 MS 윈도우가 90% 이상의 압도적인 점유율을 가지고 있지만 서버 운영체제에서는 유닉스 계열의 운영체계가 주종이고 윈도우 서버는 20-30%에 머무르고 있다. 또 윈도우는 그래픽 기반의 GUI는 매우 우수하나, 시스템 콘솔과 명령줄 도구들은 20년 전 MS-DOS 시대보다 크게 낫다고 하기 어려울 만큼 원시적이다. 그래서 명령줄 도구를 자주 사용해야 하는 시스템 관리자들이나 개발자들을 위해 윈도우에서도 유닉스 계열의 우수한 명령어 기반 도구들을 사용하기 위한 여러 방법과 도구들이 나와 있다.
윈도우는 윈도우 2000 시절부터 윈도우 커널 수준에서는 유닉스의 POSIX 표준을 지원하는 기능을 가지고 있었다.

2. Xenix


마이크로소프트가 유닉스 계열의 OS를 판매한 건 의외로 역사가 길다. 마이크로소프트는 1980년대 초에 유닉스의 초창기 버전인 AT&T system 7 소스를 인텔 286 계열 PC와 모토롤라 68000 CPU에 이식하여 Xenix라는 제품명으로 SCO 등과 공동으로 판매했으나, 이 사업은 결국 SCO가 전담하고 마이크로소프트는 손을 뗀 후 윈도우 개발에 전념한다.

3. SUA


WSL이 나오기 이전에 윈도우 XP나 윈도우 7 등에서는 Subsystem for UNIX-based Applications(aka SUA)라는 것이 있었지만, 리눅스와의 호환성이 부족해서 일부 서버 어플리케이션 외에는 널리 사용되지 않았다.

4. Cygwin


윈도우용 리눅스 에뮬레이터. 아래의 WSL과 흡사하나 커널 레벨에서 명령어 처리를 지원하지는 않으므로 WSL에 비해 속도는 뒤쳐진다. 공식 웹사이트 가상화 기술을 사용하는 소프트웨어가 아니기 때문에 리눅스 애플리케이션을 그대로 구동할 수는 없고, Cygwin 환경에 맞게 소스 레벨에서 리컴파일이 필요하다.
Cygwin의 각종 도구는 윈도우의 콘솔 창에서도 동작하지만 따로 bash shell 창이나 mintty 등의 윈도우 콘솔 에뮬레이터를 띄우면 마치 실제 유닉스 시스템에 터미널을 접속한 것처럼 쓸 수도 있다. 원시적인 윈도우 콘솔의 불편한 점을 보완해 윈도우의 범용성과 유닉스 콘솔의 편리한 점을 모두 한 PC에서 누릴 수 있다.

5. Windows Subsystem for Linux (WSL)



5.1. WSL 1


마이크로소프트가 2015년 11월 윈도우 10의 RS1 업데이트를 발표하며 나온 시스템. 리눅스의 주요 배포판인 우분투의 개발사 캐노니컬과 협력하여 리눅스 서브시스템을 NT 커널 내부에 탑재하였다. API 수준에서 리눅스와 호환될 뿐만 아니라 Bash도 사용 가능하며, 리눅스용 ELF 바이너리를 컴파일 없이 리눅스와 동일한 절차로 바로 설치해 실행시킬 수 있다. 윈도우에 기본으로 들어있는 시스템은 아니지만 마이크로소프트 스토어에서 무료로 다운받을 수 있다. 현재 우분투, 데비안, openSUSE, 칼리 리눅스가 지원되고 있다.
특기할 만한 점이라면 WSL은 리눅스 커널을 사용하는 시스템이 아니라는 것이다. 대신 윈도우 10의 NT 커널 내부에 추가된 Pico provider 드라이버(lxss.sys, lxcore.sys)를 사용한다. Pico provider는 Bash에서 전송한 리눅스 시스템 콜을 NT API 콜로 변환하거나, 반대로 NT 커널에서 처리한 결과를 리눅스 시스템 콜의 반환 형식으로 변환한다. 즉, NT 커널이 리눅스 커널에 대한 일종의 에뮬레이터 역할을 하는 것이다.[1][2] 리눅스용 ELF 바이너리는 Win32/UWP 바이너리를 위한 NT process로부터 독립된 Pico process 컨테이너 내에서 실행되며, 리눅스 시스템 콜의 반환 값이 이곳으로 전송된다. 이러한 시스템을 통해 ELF 바이너리를 수정 없이 WSL에서 그대로 실행할 수 있는 것이다.
또한 리눅스의 기존 파일 시스템을 그대로 사용하기가 어려워 MS가 자체 개발한 파일 시스템이 사용되었는데, 그 종류에는 DriveFS와 VolFS가 있다. DriveFS는 윈도우와의 상호 운용성을 지원하기 위한 파일 시스템으로서, '''/mnt/c''' 또는 '''/mnt/d''' 등으로 마운트되는 것이 특징이다. VolFS는 완전한 리눅스 파일 시스템의 구현을 목적으로 하는 시스템이며, WSL의 '''/home, /bin , /etc''' 등의 디렉토리에 적용되어 있다.
리눅스는 양쪽의 파일시스템을 읽을 수 있지만 윈도우는 윈도우 파일만 읽고 쓸 수 있다. 때문에 VS Code 등의 윈도우 프로그램을 사용할 때는 파일시스템 이용을 할 때에 주의가 필요하다. 리눅스 프로그램 설치를 할 때는 cd ~ 를 통해 우분투 루트를 통한 리눅스 파일 시스템을 이용하고, 직접 프로젝트 파일을 다룰 때에는 /mnt/c/ 를 통한 윈도우 파일시스템으로 나와서 작업을 해야 한다.
CLion 같은 일부 IDESSH 통신을 이용하여 WSL에 설치된 컴파일러로 원격 컴파일하는 기능을 제공하는데, 이를 이용하면 '윈도우에서 개발 + 리눅스에서 컴파일'이라는 두 가지 환경을 동시에 구축할 수도 있다. 비주얼 스튜디오 코드의 C/C++ 플러그인은 설정 파일(settings.json)에
"C_Cpp.default.intelliSenseMode": "gcc-x64"
또는
"C_Cpp.default.intelliSenseMode": "clang-x64"
를 추가하면 WSL에 설치된 GCCClang 컴파일러를 기준으로 인텔리센스를 적용한다.
정식으로 지원되는 것은 주로 사용자용 문자 콘솔 위주의 명령어들이지만 X 윈도우 서버 등 그래픽 서버를 설치하면 GNOME 등 리눅스의 GUI 그래픽 어플리케이션도 지원이 되고 백그라운드에서 수행되는 daemon 프로그램도 사용할 수 있다. 다만 일부 커널 레벨의 시스템 권한이 필요한 도구들은 지원되지 않는다. systemd도 아직은 지원하지 않으니 참고할 것.
WSL 2가 발표되었지만 상당한 안정화가 되어 매우 쓸만해졌다. 아직은 WSL 2가 시험단계이므로 도전적이지 않은 사람들은 이쪽을 이용해 보는 것도 좋다.

5.2. WSL 2


2019년 6월부터 WSL 2의 베타 버전이 윈도우 참가자 프로그램을 통해 공개되었다. WSL 1과는 다르게 WSL 2는 Hyper-V 기반의 최신 가상화 기술을 이용하여 '''실제 리눅스 커널'''을 직접 탑재하였다. 이에 따라 모든 시스템 콜이 완벽하게 호환되며, 성능 또한 비약적으로 상승하였다고 한다.[3] 20H2 업데이트에 포함되어 배포되었다. #
[image]
WSL 2의 구조도. Hyper-V 마이크로커널 위에 윈도우의 NT 커널리눅스 커널이 병렬적으로 올라가서 실행된다는 것을 알 수 있다. # Windows 10 1904 Home 버전에서는 WSL 1.0이 설치되고, Build 19603부터 WSL 2.0을 설치할 수 있다. #
WSL 2.0에서는 우분투의 루트 파일시스템이 ext4의 가상 하드디스크(ext4.vhdx)로 마운트된다. 이는 윈도우의 File Explorer에서도 WSL에 설치한 우분투의 루트 파일시스템을 수정 및 확인하는 것이 가능해진다는 뜻이다. # 물론 NTFS/FAT 등 윈도우의 파일시스템도 직접 다룰 수 있다. NTFS 파일시스템으로 설치된 윈도우 C:/는 WSL에서 /mnt/c로 마운트되고, 다른 하드디스크 D:/와 E:/가 있다면 /mnt/d와 /mnt/e로 WSL에서 바로 접근 가능하다. USB 드라이브는 별도의 명령어를 통해서 마운트 할 수 있다.[4] 그리고, ext4로 포맷된 별도의 드라이브 파티션은 WSL에서 인식하지 못한다. 확인결과 우분투와 윈도우의 파일 공유 방법 systemd 또한 여전히 지원하지 않는다.
[image]
[image]
ext4의 가상 드라이브로 마운트되는 WSL 2의 Ubuntu 20.04가 File Explore에서 확인되는 모습.
[image]
WSL 2 위에서 KDE 데스크탑을 실행하는 모습. KDE 데스크탑이나 GNOME 데스크탑 등을 설치해서 GUI 환경을 만들 수 있다.
그래픽 하드웨어와 같은 장치에도 액세스가 가능하다.
WSL 2.0의 성능은 MS에서 지속적으로 개선을 진행하고 있지만, 다른 VM과 동일하게 Host PC의 리소스를 활용하기 때문에 떨어지는 경향이 있다. WSL 2.0에서는 VM RAM은 윈도우의 80%, swap의 크기는 25%를 기본값으로 설정하고 있다. WSL 2.0 사용 목적에 따라서 CPU 개수, RAM 크기, swap 크기를 조정할 필요가 있다. 이는 윈도우 빌드 ID 19041 이후 버전에서 가능하고, 윈도우 사용자 폴더에 .wslconfg 파일을 생성하면 된다. 작성법
마이크로소프트에서 향후에 공식적으로 GUI를 지원할 예정이라고 한다.[5] #
[image]
위 그림은 XDC 2020에서 공개한 WSLG(WSL Graphics Architecture)의 구조도이다.
WDDM(Windows Display Driver Model) 2.9부터 DirectX 가속이 예정되어 있으며, 이를 통해 WSL에서의 GPU 가상화를 지원할 것이라고 한다.

6. 기타


마이크로소프트가 2019년 5월에 발표한 윈도우 터미널을 사용하면 Cmd, 파워셸, WSL Bash를 하나의 콘솔 내에서 함께 사용할 수 있다. 현재 윈도우 스토어에 무료로 출시되었으며, GitHub에 소스 코드가 공개되었다.
MobaXterm에서도 WSL 터미널을 지원하고 X-Server를 이용해서 GUI 프로그램 실행도 가능하다. #1#2

[1] 이는 MS Research 팀이 연구한 DrawBridge 프로젝트의 산물이다.[2] 따라서, 에뮬레이팅 방식의 한계로 인해 WSL이 모든 리눅스 시스템 콜을 처리하지는 못한다.[3] 실제로 Windows의 NT 커널 자체는 PC의 하드웨어와의 호환성이 낮아 8.1까지는 WoW 마이크로커널(다들 알겠지만 아주 느리다. Windows 8.1과 10의 실제 사용시 체감 성능이 크게 다른 것도 여기에 기인한다.) 위에서 돌아갔고, 10은 Hyper-V 마이크로커널 위에서 돌아간다. 이렇게 하면 '''Windows 10이 RS3 이전까지는 매우 불안정했던 이유'''를 설명할 수 있다. Hyper-V의 개발이 RS3 때 공식적으로 완료되었기 때문. WSL 1이 Windows 10 Home에 적용된 것도 이때이다.[4] sudo mount -t DrvFs (드라이브명): /mnt/(드라이브명)[5] 공식지원하게 된다면 따로 설정없이 바로 쓸 수 있게 된다.