# Win32/Linux를 함께 구축하자: loss32 프로젝트

> Clean Markdown view of GeekNews topic #25471. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25471](https://news.hada.io/topic?id=25471)
- GeekNews Markdown: [https://news.hada.io/topic/25471.md](https://news.hada.io/topic/25471.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-01T04:34:06+09:00
- Updated: 2026-01-01T04:34:06+09:00
- Original source: [loss32.org](https://loss32.org/)
- Points: 3
- Comments: 1

## Topic Body

- **loss32**는 **WINE과 ReactOS 구성요소**를 활용해 **Win32 환경을 기본 데스크톱으로 사용하는 Linux 배포판**을 목표로 함  
- 사용자는 **.exe 파일을 직접 다운로드해 실행**할 수 있으며, 완전한 **오픈소스 운영체제** 형태로 설계됨  
- **ReactOS**가 Windows NT 커널을 재구현하려는 접근과 달리, loss32는 **Linux 커널 위에서 안정성과 호환성을 확보**하려는 방향  
- 프로젝트는 **WINE 개선**, **Win32 기반 데스크톱 경험 복원**, **창작용 소프트웨어 접근성 확대**를 주요 동기로 함  
- 2026년 1월 **초기 프로토타입 배포**가 예정되어 있으며, 이후 점진적 개선 계획  

---

### Win32/Linux 개념
- Linux는 단독 운영체제가 아니라, **WINE과 ReactOS 사용자 영역** 등으로 구성된 **완전한 시스템의 일부**로 설명됨  
  - 이 조합을 **“Win32/Linux”** 또는 **“Win32 plus Linux”** 로 명명  
- Microsoft가 정의한 완전한 OS 개념을 기반으로, **Linux 커널과 Win32 환경의 결합**을 지향  

### 프로젝트 개요
- 목표는 **WINE 위에서 Win32 소프트웨어로 구성된 전체 데스크톱 환경**을 구축하는 것  
  - 사용자는 **.exe 파일을 직접 실행**할 수 있음  
  - Unix 지향 사용자가 아니더라도 접근 가능한 **자유롭고 개방된 OS** 형태  
- **ReactOS와 달리 커널을 새로 구현하지 않으며**, **Linux 커널과 검증된 구성요소**를 사용  
  - ReactOS 사용자 영역 일부를 포함해 **사용성 향상**을 도모  
  - Linux 기반이므로 **Linux용 소프트웨어 실행도 가능**, ReactOS에는 없는 장점  

### 사용자 영역 대체 범위
- 가능한 한 **전체 사용자 영역을 WINE으로 대체**하는 방향  
- 구체적 제한이나 예외는 언급 없음  

### 구축 동기
- **1990년대 후반~2010년대 초반 PC 데스크톱 경험**을 유지하고자 함  
- **WINE의 불완전한 부분을 개선**해, 모든 사용자가 더 나은 호환성을 누릴 수 있도록 함  
- **Win32를 “안정적인 Linux ABI”** 로 간주  
- 단순히 “가능하기 때문”이라는 실험적 동기도 포함  

### Win32의 안정성 주장
- **Win32 ABI**는 수십 년간 유지된 **호환성 기록**을 가짐  
  - WINE을 통해 **Win16 소프트웨어까지 실행 가능**  
- 창작 소프트웨어나 게임 등 **GNU/Linux 생태계에서 부족한 분야**에서도 Win32는 폭넓은 접근성을 제공  
- **“세계의 안정적 ABI”** 로 표현되며, 문화적 유산에 대한 접근성을 높이는 역할로 평가됨  

### 스크린샷 및 현재 상태
- 공개된 스크린샷은 **Debian 13에서 WINE이 실행 중인 실제 화면**  
- 현재는 **불편한 요소와 미완성 부분**이 존재  
- 목표는 **이 환경을 안정화하고 손쉽게 설치 가능한 형태로 패키징**하는 것  

### 참여 방법
- 프로젝트는 **hikari_no_yume**가 2025년 12월 29일 **39C3 행사 중 작성**, 12월 30일에 갱신  
- 참여 또는 문의는 **이메일(hikari@noyu.me)** 또는 **IRC 채널 #loss32 (irc.libera.chat)** 을 통해 가능  
- 협력 희망 분야:
  - **Wayland 컴포지터**와 WINE의 통합 개선 (현재 standalone mutter 사용 중)
  - **WINE의 explorer.exe, shell32.dll, HiDPI 스케일링, 패키징** 관련 작업
  - **ReactOS의 explorer.exe, shell32.dll, WINE과의 호환성 문제**
  - **GNU/Linux 데스크톱 스택 세부 구조** 전반  

### 향후 일정
- **2026년 1월**에 **초기 프로토타입 배포 예정**  
  - `/etc/apt/sources.list`에 추가 후 `sudo apt install`로 설치 가능 형태  
  - 다수의 **미완성·결함 요소**가 포함될 예정이며, 이후 **반복적 개선 과정** 진행 예정

## Comments



### Comment 48531

- Author: neo
- Created: 2026-01-01T04:34:06+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46424173) 
- Linus Torvalds조차 **ABI 호환성**이 충분하지 않다고 말했음. 이것이 Linux가 데스크탑에서 인기가 없는 주요 이유 중 하나라고 생각함  
  [관련 영상](https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s)
  - 친구의 말을 빌리자면, “Glibc는 완벽히 안정적인 커널 ABI를 낭비하고 있음”이라는 표현이 딱 맞음
  - AppImage나 FlatPak 같은 포맷이 이 문제를 **이론적으로 해결**하지만, 오래된 소프트웨어를 패키징할 사람이 없다는 게 현실적인 문제임
  - 이 주장은 여전히 일리 있지만, **12년 전 이야기**라는 점도 짚고 넘어가야 함
  - Linus의 의견에 전적으로 동의함. Windows에서는 WinXP용 exe가 Win10, 11에서도 거의 항상 실행되지만, Linux에서는 Mint나 Ubuntu 버전이 바뀔 때마다 **호환성 문제**로 고생함
  - 이런 이유로 OpenBSD가 매력적으로 보일 수도 있음. 커널과 앱이 완전히 통합되어 있고, 단순함 덕분에 **보안성과 안정성**이 높음.  
    하지만 오픈소스 진영이 이렇게 오래된 개념 위에서 여전히 불안정한 OS를 만든다는 건 아이러니함.  
    패키징 시스템의 혼란, 깨지는 업데이트, 불안정한 glibc, 계속 바뀌는 데스크탑 환경 등은 여전히 문제로 남아 있음

- Wine과 Proton 덕분에 Linux가 **오래된 Windows 게임**과 더 잘 호환되는 게 놀라움. 90~00년대 게임들이 Windows에서는 실행하기 어렵지만, Steam에서는 클릭 한 번으로 Linux에서 돌아감
  - 사실 Wine은 Windows에서도 작동함. Shorthorn 프로젝트가 XP에서 최신 소프트웨어를 돌리기 위해 사용함
  - 내 게이밍 PC는 Windows 11과 호환되지 않아 Linux로 바꿨는데, 체감상 **성능 향상**이 즉각적이었음. Windows는 불필요한 다운로드와 충돌이 많았지만, Linux에서는 대부분 잘 작동함. 다만 Proton에서 일부 게임의 **사운드 문제**는 남아 있음
  - 어떤 게임들이 Windows에서 실행하기 어려운지 구체적인 예시가 궁금함
  - 반대로, Linux 네이티브 버전의 게임이 안 돌아서 Windows 버전을 Proton으로 돌려야 했던 적도 있음

- VB6 기반으로 GUI 유틸리티를 만드는 게 요즘의 웹 기술보다 **안정적이고 생산적**일 수도 있음
  - 나는 Delphi를 선택하겠음. [Delphi](https://www.embarcadero.com/products/delphi)는 Windows, Linux, macOS, Android, iOS 모두 지원함.  
    또 RemObjects의 Elements는 다양한 언어로 여러 플랫폼을 타깃할 수 있는 RAD 환경임
  - 나도 VB6로 시작해서 향수가 있지만, **React의 선언적 UI 모델**이 가져온 발전은 부정할 수 없음. 초기 렌더와 재렌더의 구분이 사라지고, 상태 업데이트만으로 UI가 갱신되는 구조는 혁신적임
  - Delphi나 FreePascal 쪽에 한 표를 던지겠지만, 기본적인 감정에는 공감함
  - 게다가 2005년용 소프트웨어가 오늘날 시스템에서 **엄청 빠르게** 돌아감
  - 단, Win32의 기본 위젯과 효과만 쓸 때 얘기임. 그 이상을 하려면 웹 런타임처럼 **성숙하고 문서화된 환경**이 더 생산적임

- Linux의 ABI 문제를 구체적으로 알고 싶음. 20년 넘게 Linux를 써왔지만, 패키지 매니저를 통해 설치한 앱에서는 문제를 느끼지 못했음.  
  혹시 전체 역사를 아는 사람이 있다면 블로그로 정리해주면 좋겠음
  - 커널은 안정적이지만, 그래픽 앱에 필요한 시스템 라이브러리들이 자주 깨짐. GTK, Qt, X11 등 주요 구성요소가 계속 바뀌며 **호환성 단절**이 발생함
  - 실제 문제는 ABI가 아니라 **표준화 부재**임. [Linux Standard Base](https://en.wikipedia.org/wiki/Linux_Standard_Base)가 이를 해결하려 했지만 관심 부족으로 사라짐.  
    유지보수가 재미없다는 이유로 **CADT(Rewrite 문화)** 가 계속되고 있음. 예: Wayland, Rust 리라이트  
    이런 환경에서는 상용 앱이 성장하기 어렵고, 오픈소스 앱도 포팅에 수년이 걸림 (예: GIMP의 GTK2→3 전환)
  - Linux는 Windows처럼 전체 스택을 포괄하지 않음. 여러 개발자의 라이브러리가 섞여 있고, 시간이 지나며 계속 변함
  - GLIBC 버전 문제를 겪어본 적 없는지 궁금함
  - 매번 OS 릴리스마다 전체를 **패치하고 재컴파일**하는 모델은 끔찍함.  
    개발자는 배포판 중간자 때문에 고통받고, 사용자는 구버전 앱만 써야 함.  
    좋은 OS라면 과거 앱을 그대로 실행할 수 있어야 함.  
    Windows는 이 점에서 Linux보다 훨씬 낫고, Linux는 **사회주의적 구조**라 책임 주체가 없음.  
    Docker가 서버 쪽에서는 해결책이지만, 데스크탑에는 적용되지 않음

- Windows 7이나 XP 같은 **클래식 UI**를 가진 Linux 데스크탑이 있다면 정말 팬이 될 것 같음.  
  그 우아함은 Windows 10보다 훨씬 매력적임
  - 놀랍게도 완성도 높은 1:1 XP/7 클론 DE가 아직 없다는 게 신기함.  
    이런 고정된 환경을 복제하면 **기능 과잉**을 막고, 버그 수정과 최적화에 집중할 수 있을 것임
  - [KDE용 Aero 테마](https://github.com/ivvil/aerothemeplasma)를 써보길 추천함. 스크린샷만 보면 진짜 Windows 7처럼 보임
  - 하지만 이런 시도는 대부분 실패함. [Linspire](https://en.wikipedia.org/wiki/Linspire)나 [BeOS PC](https://www.osnews.com/story/136392/the-only-pc-ever-shipped-with-beos-preinstalled/)처럼 **하드웨어와 함께 출하되지 않으면** 유지가 불가능함
  - [SerenityOS](https://github.com/SerenityOS/serenity)는 Win2k 스타일의 완전한 OS로, 하드웨어 지원만 갖추면 가능성이 있음.  
    아니면 ReactOS가 완성되길 기다려야 함
  - XFCE에 Windows 테마를 입히면 꽤 비슷한 경험을 얻을 수 있음. 거기에 Wine 설정을 추가하면 충분함

- Python과 WxWindows 버전 변화로 **WikidPad**가 깨져서 결국 Windows로 돌아왔음.  
  2012년 exe는 여전히 완벽히 작동함. 개인적으로 **Windows 2000 Server SP4**가 최고의 데스크탑 OS였다고 생각함
  - Cutler가 감독한 마지막 버전인 Server 2003이 내 선택임. 기술적으로 **소스 접근도 가능**함
  - Debian에서도 비슷한 문제를 겪었지만, debootstrap과 snapshots.debian.org로 해결함.  
    GPU 가속은 깨질 수 있지만 X11은 여전히 **강력한 하위 호환성**을 유지함
  - 2025년에 이르러서도 “Task Manager가 CPU 15%를 먹는다”는 말을 듣는 걸 보면, Windows 11은 여전히 **비효율적**임

- Microsoft가 이제 자신들이 만든 **embrace, extend, extinguish** 전략의 맛을 볼 때가 됐다고 생각함
  - 내 생각엔 Windows 13은 **Linux 커널 기반**으로 전환할 수도 있음.  
    실제로 Microsoft는 지난 10년간 Linux와 오픈소스를 적극적으로 수용해왔음

- Linux의 아이디어는 좋지만, 여전히 **하드웨어 지원**이 부족함. ARM이 확산되면 더 악화될 것 같음.  
  Google이 왜 Android를 진짜 데스크탑 OS로 만들지 않는지 의문임. ChromeOS는 너무 제한적임
  - 사실 Linux는 장치에 따라 다르지만 **Windows보다 호환성이 나은 경우도 많음**.  
    Google은 Android 16부터 데스크탑화를 진지하게 추진 중임.  
    ChromeOS도 특정 작업에는 충분히 훌륭함.  
    다만 Google은 고객의 목소리를 듣는 데는 약함.  
    그래도 웹 기술 발전에 기여한 점은 인정해야 함
  - ChromeOS는 결코 장난감이 아님. 개발 환경으로는 macOS보다 나은 부분도 있음.  
    마지막으로 써본 게 2013년이라면 지금은 완전히 다름
  - 요즘은 오히려 **Linux만 지원하는 하드웨어**도 많음
  - 데스크탑 환경에서는 대부분의 하드웨어가 바로 작동함. 특이한 장비만 아니면 **문제 없음**

- 주요 배포판들이 **binfmt_misc**를 이용해 Wine을 기본 등록해주면 좋겠음.  
  Windows 앱을 Linux 보안 메커니즘 안에서 격리 실행하고, 로그와 크래시 리포트를 통합 관리하면  
  **Windows 대체 OS**로서 현실적인 길이 열릴 것임
  - 이런 기능이야말로 Linux를 **초보자 친화적**으로 만드는 핵심임

- [Longene](https://en.wikipedia.org/wiki/Longene) 프로젝트가 다시 떠오름.  
  Linux 커널에 Windows API를 통합하려던 시도로, 흥미로운 역사적 참고 사례임