▲

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

 (loss32.org)
3P by GN⁺ 6일전 | ★ favorite | 댓글 1개
  • 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로 설치 가능 형태
    • 다수의 미완성·결함 요소가 포함될 예정이며, 이후 반복적 개선 과정 진행 예정
▲
GN⁺ 6일전  [-]
Hacker News 의견들

  • Linus Torvalds조차 ABI 호환성이 충분하지 않다고 말했음. 이것이 Linux가 데스크탑에서 인기가 없는 주요 이유 중 하나라고 생각함
    관련 영상

    • 친구의 말을 빌리자면, “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는 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가 이를 해결하려 했지만 관심 부족으로 사라짐.
      유지보수가 재미없다는 이유로 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 테마를 써보길 추천함. 스크린샷만 보면 진짜 Windows 7처럼 보임
    • 하지만 이런 시도는 대부분 실패함. Linspire나 BeOS PC처럼 하드웨어와 함께 출하되지 않으면 유지가 불가능함
    • SerenityOS는 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 프로젝트가 다시 떠오름.
    Linux 커널에 Windows API를 통합하려던 시도로, 흥미로운 역사적 참고 사례임

답변달기