윈도우 / MS 이전 글에서 언급한 대로 Linux Subsystem이 추가 됨

automake나 Configure스크립트, bash스크립트, gcc 제대로 되는지?

최저한도 이 4개가 제대로 안 작동하면 네이티브 바이너리는 커녕 컴파일 스크립트조차 제대로 안 됩니다

위와 같이 rootfs 아래로 리눅스 기본 디렉토리가 생성 됩니다. Windows 10 에 Ubuntu로 패키징 되어있는 리눅스 파일시스템을 갖고 있다고 보면 됩니다. 물론 패키지는 리눅스용으로 컴파일 되어있는 Pure ELF 형식의 바이너리 입니다. Native Linux Subsystem Layer를 통해서 Linux Kernel System call 레이어를 시스템 레벨에서 지원하기 때문에. bash 리눅스 쉘 그대로의 환경과 마찬가지로 작업하면 됩니다.

Win32 PE 형식의 bash.exe는 실제 적인 쉘이 아니고 rootfs 시스템이 초기화 되어있지 않으면 셋업하고, 셋업되어있으면 실제적인 리눅스 쉘 역할을 하는 rootfs/bin/bash EFL 형식의 리눅스 바이너리가 실행되게 됩니다. bash.exe Win32 프로그램은 일종의 house-keeping 역할만 하게 됩니다.

Linux Development 패키지는 디폴트로 셋업에 포함되어 있지 않습니다. 실제 리눅스에서 처럼 필요한 Development 패키지를 apt-get으로 내려 받아서 설치하면 됩니다. 출근 때문에 바빠서...

정보 감사합니다.

요즘 MS 하는 짓 보면 이뻐 죽겠지 말입니다.ㅎㅎ

좋은 정보 감사합니다

14316 설치완료 했는데 32비트라서인지 배시는 포함되지 않았습니다.

x64 버전에만 포함된건가요?

64비트 설치해야 되네요

GCC 컴파일러 툴체인 소스코드를 빌드해서 컴파일러 바이너리를 만들어 봤는데, 실제 리눅스 OS에서 작업하는 것과 동일한 결과가 나옵니다. auto tool, build script 정상적으로 수행되고. CPU 가상화 해서 하이퍼바이저 레이어 위에서 돌리는 것 보다 리소스도 안먹고 가볍네요. Windows OS 위에서 다이렉트로 돌아가다 보니 빠를 수 밖에 없는. Win32 API를 이용한 에뮬레이션 환경 보다 더 리눅스 쉘 환경에 가깝고. 아직 베타 단계라서 모든 Linux Kernel API가 Windows 10 Linux Subsystem 레이어를 통해서 지원되는 건 아니지만. 이건 계속 다듬어 질테고.

Native Linux Subsystem 레이어에서 리눅스 쉘 환경을 테스트 하기 위해 GCC 컴파일러 툴체인 소스코드를 빌드해서 컴파일러를 만들어 본 결과, 실제 리눅스 OS에서 작업한 것과 동일한 결과를 얻을 수 있었고, 빌드된 컴파일러 바이너리로(Pure ELF64 실행파일) 컴파일도 정상적으로 됨을 확인 할 수 있었다.

Windows 10 14316 빌드가 아직 까진 여러 버그를 갖고 있어서 일반 엔드유져 사용자들이 실컴에서 사용하기는 적절해 보이지 않지만, 크로쓰 플렛폼을 개발하는 개발자 들은 실컴에 설치해서 사용해 봐도 좋을 듯 싶다. 

어카운트는 root 싱글유저 시스템 같습니다..(무비번)

.deb Repository 경로도 모두 죽은 경로로 돼있어 한국주소로 직접 수정해줘야 apt-get을 쓸수 있습니다.

실제 커널이 부팅되는게 아니라 dmesg로 아무것도 볼수 없고 ifconfig도 안됩니다.

유니코드지만 로케일은 오직 EN-US 이며 / 위치는 로컬이 아닌 클라우드상에 있다고 나오네요. (중요)

이로서 리눅스 클라우드 버전이 아닐까 합니다

결론적으로 리눅스로 어떤 작업을 하고있다면 기존 방식대로 하는게 정신건강에 좋으며

윈도에서 정 리눅스 커멘드를 써보고자 한다면 busybox-win32가 있습니다.

https://frippery.org/files/busybox/busybox.exe

정보 잘보고 배우고 있습니다. 마소가 화합으로 진로를 변경하니 이런것도 보게 되는군요.

클라우드 기반이 맞는거같네요. 64비트로 깔았는데 이렇게 뜨면서 개발버전 쓰라고 나오네요.