"container" 프로젝트에 기여를 환영하고 장려한다는 메시지 상당히 이례적인 애플의 태도로 느껴짐
WebKit은 KHTML의 적대적 포크였고, Darwin도 마치 벽 너머로 부품을 띄엄띄엄 던져준 느낌이었음
애플이 최근 GitHub에 공개한 이런 프로젝트들에서 사용자·개발자 협업이 활발해지길 바라는 마음
나는 F/OSS(오픈 소스) 성향이지만, 회사 정책 때문에 리눅스를 못 쓰고 어쩔 수 없이 매일 Mac을 쓰는 사람
애플 실리콘 도입 이후 집에서 쓰는 노트북도 Mac으로 바꿨지만, 요즘에는 리눅스에 친화적인 대안들도 점점 가까워지는 추세라 기대감 큼
이런 변화는 긍정적인 신호이고, 나처럼 내적 갈등 있었던 사용자에게는 마음이 놓이는 변화
혹시 이런 오픈소스 협업이 선순환 구조로 이어진다면 애플과 커뮤니티 사이 협업 문화가 더 커질 수 있을 것이라고 생각
나 같은 개발자들이 이런 변화에서 직접적인 혜택과 동시에 애플에 대한 존중까지 얻을 수 있는 분위기라고 상상함
애플이 오픈 소스 커뮤니티 참여에 대해 그리 놀라울 필요는 없다는 의견
Swift 및 그 관련 프레임워크들에도 오픈 소스 커뮤니티의 기여가 많다는 사실 언급
이 프로젝트가 리눅스를 다루다 보니, 리눅스의 카피레프트(강한 오픈소스 라이선스) 때문에 애플이 협업 방식을 취할 수밖에 없다는 시각
Docker 입장에선 어떤 기분일지 궁금
Docker for Desktop 사용자 상당수가 Mac을 쓸 것 같다는 상상
이번 변화가 오히려 Docker Desktop 개발을 훨씬 수월하게 만들어준다는 의견
이제는 독자적으로 리눅스 VM을 세팅하지 않아도 되므로 개발난이도 완화
그래도 많은 사용자가 익숙한 CLI, Docker Compose, 다양한 Docker 독자적 UX 때문에 기존 Docker Desktop을 선호할 것이라는 예측
컨테이너 런타임을 바꾸는 것은 쉽지 않은 일이라는 설명
Docker 입장에서는 podman을 대할 때와 비슷한 감정일 것이라는 추측
Docker Desktop이 닫힌 소스의 상용 소프트웨어이고, 이번 프로젝트는 자유 소프트웨어이기 때문에 사용자 입장에서는 좋은 소식이라는 생각
이 기술이 Linux 컨테이너를 MacOS 앱에 번들링하는 데 쓸 수 있는지 궁금
예시로, 예를 들어 GPT 같은 도구가 루트 CLI 명령어 없이도 Linux 환경에 접근하게 할 때 필요성 존재
MacOS 26에서만 동작해도 괜찮다면, 바로 원하는 목적에 쓸 수 있다는 안내
아니면 Virtualization.framework를 직접 사용해서도 가능하지만, 추가 작업이 더 필요하다는 설명
바로 이런 목적을 위해 나온 기술이라는 확신
컨테이너마다 각기 분리된 VM으로 실행되어 완전 격리와 독립된 IP 부여 등 흥미로운 구조이지만, 이런 설계가 리눅스나 윈도우에서는 익숙하지 않음
개발팀에서 한 명이라도 맥을 쓰지 않는다면 로컬 개발 모델이 깨져버리는 단점
Docker/Compose를 대체하기는 쉽지 않을 것이라는 결론
주요 데스크톱 OS 세 개 중 두 곳이 이제 공식적으로 리눅스 VM을 구동해서 리눅스 네이티브 애플리케이션을 실행할 수 있게 됨
이 흐름을 보면 리눅스가 사실상 이겼다는 주장 가능
리눅스 시스템콜 API는 이제 거의 모든 곳에서 동작하는 범용 API 위치
두 개의 주요 비리눅스 OS 위에서 리눅스 기반 애플리케이션 개발이 정상적으로 이뤄져야 한다는 사실 자체가 "리눅스의 승리"라고 보기엔 어렵다는 반론
데스크톱 리눅스의 현실이 여전히 불안정하고 추천하기 힘들다는 경험담
매년 Fedora/Ubuntu를 최신 PC나 랩톱에 설치해 봐도 여전히 사용성과 안정성을 못 느낀다는 솔직한 피드백
오히려 다른 두 플랫폼이 리눅스를 떠나지 않고 쓸 수 있는 방식을 제공하면서 데스크톱 시장에서 리눅스 자체의 점유율 증가를 더디게 만든다는 시각
그래픽, 오디오, GUI 쪽에는 아직 제대로 된 솔루션이 없다는 단점 부각
"게임에 참가한 플레이어가 본인밖에 없으면 이긴 것일까"라는 의문 제기
평범한 Windows, Mac 사용자에게 말해봤자 리눅스가 뭔지조차 모르는 상태라고 농담
"리눅스와 함께하는 macOS"라는 사실 자체가 임팩트라는 의견
이들이 메모리 관리(필요 이상으로 VM이 메모리를 쓰지 않는 구조)도 최적화했는지 궁금
어떤 과정인지 정확히는 모르겠으나, 빌드 속도가 너무 느린 느낌
-c, -m 옵션으로 CPU/메모리 자원 더 늘려봤지만 효과 체감 미흡
어떤 환경과 비교해서 느린지 궁금
과거 실리콘 Mac + Rancher Desktop 조합에서 x86 이미지를 빌드하는 척 했지만, 실제 x86 하드웨어에서 그 이미지들이 제대로 동작하지 않은 경험 공유
Hacker News 의견
가장 놀랍고 흥미로운 부분이라고 생각하는 내용 공유함
애플이 오픈 소스 커뮤니티 참여에 대해 그리 놀라울 필요는 없다는 의견
Swift 및 그 관련 프레임워크들에도 오픈 소스 커뮤니티의 기여가 많다는 사실 언급
이 프로젝트가 리눅스를 다루다 보니, 리눅스의 카피레프트(강한 오픈소스 라이선스) 때문에 애플이 협업 방식을 취할 수밖에 없다는 시각
관련 비디오로 WWDC 2025 발표 영상(https://developer.apple.com/videos/play/wwdc2025/346/) 추천
각 컨테이너가 가벼운 리눅스 VM으로 분리되는 구조임
container 툴 다운로드로 직접 구동 가능(https://github.com/apple/container/releases), macOS 26 필요
이번 제출 건은 https://github.com/apple/containerization 이지 container 프로젝트와는 다름
containerization은 앱이 컨테이너 사이드카와 함께 배포되는 용도라 더 흥미로운 소식
반면 container는 개발자가 'docker run ...' 같은 환경을 쓰기 위한 목적
container 관련해서는 별도 HN 스레드(https://news.ycombinator.com/item?id=44229239) 안내
macOS 15에서도 동작 가능한데, 일부 네트워킹 기능은 제한될 수 있다는 점 참고
보도자료 및 WWDC 세션에서 CLI 툴이 https://github.com/apple/container 에 있다는 점 언급
이런 툴에 관심 많은 입장으로 최신 Xcode Beta에 기본 포함되길 기대했지만, 아직은 안 들어있음
prebuilt 패키지는 현재 준비중이지만, 작업 현황은 공개 이슈(https://github.com/apple/container/issues/54)에서 확인 가능
댓글 이후 정확히 1분 뒤에 prebuilt 패키지 출시(https://github.com/apple/container/releases/tag/0.1.0) 소식 공유
관련 논의는 별도 HN 스레드(https://news.ycombinator.com/item?id=44229239)에서 진행 중
Docker 입장에선 어떤 기분일지 궁금
Docker for Desktop 사용자 상당수가 Mac을 쓸 것 같다는 상상
이번 변화가 오히려 Docker Desktop 개발을 훨씬 수월하게 만들어준다는 의견
이제는 독자적으로 리눅스 VM을 세팅하지 않아도 되므로 개발난이도 완화
그래도 많은 사용자가 익숙한 CLI, Docker Compose, 다양한 Docker 독자적 UX 때문에 기존 Docker Desktop을 선호할 것이라는 예측
컨테이너 런타임을 바꾸는 것은 쉽지 않은 일이라는 설명
Docker 입장에서는 podman을 대할 때와 비슷한 감정일 것이라는 추측
Docker Desktop이 닫힌 소스의 상용 소프트웨어이고, 이번 프로젝트는 자유 소프트웨어이기 때문에 사용자 입장에서는 좋은 소식이라는 생각
이 기술이 Linux 컨테이너를 MacOS 앱에 번들링하는 데 쓸 수 있는지 궁금
예시로, 예를 들어 GPT 같은 도구가 루트 CLI 명령어 없이도 Linux 환경에 접근하게 할 때 필요성 존재
MacOS 26에서만 동작해도 괜찮다면, 바로 원하는 목적에 쓸 수 있다는 안내
아니면 Virtualization.framework를 직접 사용해서도 가능하지만, 추가 작업이 더 필요하다는 설명
바로 이런 목적을 위해 나온 기술이라는 확신
컨테이너마다 각기 분리된 VM으로 실행되어 완전 격리와 독립된 IP 부여 등 흥미로운 구조이지만, 이런 설계가 리눅스나 윈도우에서는 익숙하지 않음
개발팀에서 한 명이라도 맥을 쓰지 않는다면 로컬 개발 모델이 깨져버리는 단점
Docker/Compose를 대체하기는 쉽지 않을 것이라는 결론
주요 데스크톱 OS 세 개 중 두 곳이 이제 공식적으로 리눅스 VM을 구동해서 리눅스 네이티브 애플리케이션을 실행할 수 있게 됨
이 흐름을 보면 리눅스가 사실상 이겼다는 주장 가능
리눅스 시스템콜 API는 이제 거의 모든 곳에서 동작하는 범용 API 위치
두 개의 주요 비리눅스 OS 위에서 리눅스 기반 애플리케이션 개발이 정상적으로 이뤄져야 한다는 사실 자체가 "리눅스의 승리"라고 보기엔 어렵다는 반론
데스크톱 리눅스의 현실이 여전히 불안정하고 추천하기 힘들다는 경험담
매년 Fedora/Ubuntu를 최신 PC나 랩톱에 설치해 봐도 여전히 사용성과 안정성을 못 느낀다는 솔직한 피드백
오히려 다른 두 플랫폼이 리눅스를 떠나지 않고 쓸 수 있는 방식을 제공하면서 데스크톱 시장에서 리눅스 자체의 점유율 증가를 더디게 만든다는 시각
그래픽, 오디오, GUI 쪽에는 아직 제대로 된 솔루션이 없다는 단점 부각
"게임에 참가한 플레이어가 본인밖에 없으면 이긴 것일까"라는 의문 제기
평범한 Windows, Mac 사용자에게 말해봤자 리눅스가 뭔지조차 모르는 상태라고 농담
"리눅스와 함께하는 macOS"라는 사실 자체가 임팩트라는 의견
이들이 메모리 관리(필요 이상으로 VM이 메모리를 쓰지 않는 구조)도 최적화했는지 궁금
어떤 과정인지 정확히는 모르겠으나, 빌드 속도가 너무 느린 느낌
-c, -m 옵션으로 CPU/메모리 자원 더 늘려봤지만 효과 체감 미흡
과거 실리콘 Mac + Rancher Desktop 조합에서 x86 이미지를 빌드하는 척 했지만, 실제 x86 하드웨어에서 그 이미지들이 제대로 동작하지 않은 경험 공유
짧은 데모(https://developer.apple.com/videos/play/wwdc2025/346)에서 수백 밀리초 단위로 VM 부팅 가능하다는 점이 인상적
Virtualization.framework로 동작하는데, 이는 Docker desktop/Colima/UTM 등도 선택적으로 사용하던 기술
컨테이너 여러 개를 병렬로 돌릴 때 메모리 오버헤드가 궁금